Self-service discovery, refinement, and execution of automated multi-system insights

ABSTRACT

A system and method may be used to control a plurality of services for one or more facilities. A data store may receive first and second meter readings indicative of provision of services to the one or more facilities. A processor may automatically process the first and second meter readings to provide a plurality of insights, each of which provides information regarding operation of the one or more facilities. A display screen may display at least some of the plurality of insights by displaying, in connection with each of the insights, a plurality of options for acting on the insight to improve operation of the one or more facilities.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority as a continuation-in-part of U.S. Utility application Ser. No. 15/935,598 for “Self-Service Connection, Data Collection, and Automation of Metering and Building Systems, Controls, and Devices,” filed Mar. 26, 2018, which is incorporated by reference herein in its entirety.

U.S. Utility application Ser. No. 15/935,598 is a continuation of U.S. Utility application Ser. No. 14/805,205 for “Self-Service Connection, Data Collection, and Automation of Metering and Building Systems, Controls, and Devices,” filed Jul. 21, 2015 and issued as U.S. Pat. No. 9,958,291 on May 1, 2018, which is incorporated by reference herein in its entirety.

U.S. Utility application Ser. No. 14/805,205 claims the benefit of U.S. Provisional Application Ser. No. 62/035,845 for “Self-Service Connection, Data Collection, and Automation of Metering and Building Systems, Controls, and Devices,” filed Aug. 11, 2014, which is incorporated by reference herein in its entirety.

TECHNICAL FIELD

The present document relates to connection, data collection, and automation of metering and building systems, controls, and devices.

DESCRIPTION OF THE RELATED ART

Many businesses, schools, governments, and other industry groups manage buildings and other facilities in which a variety of utilities and other services are utilized. The gathering and utilization of data from such services can be complex, time-consuming, and expensive for facilities management personnel and other stakeholders who need access to these data. Without ready access to utilization data, it can be very difficult for these actors to identify or enable changes that could be used to eliminate waste and/or reduce the consumption of power, water, gas, and/or other resources; optimize the comfort of building occupants; and increase the productivity of their workforce.

In many instances, the information needed to manage facilities is plentiful, raw, and/or siloed within disparate systems. For facilities management personnel, this information can be inundating, challenging to interpret, and not readily actionable. Known systems do not sufficiently enable a user to navigate and use this information.

SUMMARY

In at least one embodiment, the systems and methods described herein may provide a central operating system for buildings that can significantly reduce or eliminate systems integration costs. This may facilitate deployment of the latest hardware or software from any vendor by allowing for instant connections.

In at least one embodiment, the operating system provides a streamlined user interface that avoids the need for the user to log into several very different systems for every building, system, or device, thus fundamentally changing the way users can interact with technology in buildings. The described system may thus provide a way to integrate information from various systems into a single, modern platform that all individuals within an organization can use for management, analysis, and/or control, as applicable.

As such, the operating system for the control of systems and devices as presented herein can fundamentally change how and where automation takes place. The system may facilitate development and deployment of new methods of control that use one or more control modes, sometimes in combination. Such methods of control may include, but are not limited to:

-   -   Scheduling-based control;     -   Demand-based control;     -   Budgeting-based control;     -   Proximity-based control;     -   Alert-based control;     -   Notification-based control; and/or     -   Behavior-based control.

Accordingly, various embodiments provide a system, method, and/or user interface whereby users can perform functions that may include, but are not limited to:

-   -   Instantly connecting building systems, meters, sub-meters,         controls, sensors, devices, as well as other data services and         software to automatically discover remote systems and data;     -   Centrally collecting, processing, and/or storing data; and     -   Automating the monitoring, configuration, and control of systems         and devices.

Such techniques can be used to solve problems such as:

-   -   System and device interoperability;     -   Self-service implementation of systems, meters, and devices;     -   Multi-modal, multi-system control; and/or     -   User interface challenges stemming from a centralized repository         of information and diversity of implementation and advanced         control sequences.

The software platform for implementing the operating system is referred to herein as “BuildingOS.” The functionality for self-service, automated, and/or one-click connection of systems is referred to as “ConnectNow.” These names are provided for ease of reference only, and are not intended to limit scope or applicability of the present disclosure.

In at least one embodiment, BuildingOS serves as a central repository or “hub” for utility meter data, sub-meter data, building controls data, billing data, and/or other building metrics. A software-as-a-service (SaaS) platform may aggregate data from metering and building technologies. Such metering and building technologies may include, but need not be limited to:

-   -   Building automation systems;     -   Sub-meters;     -   Lighting and plug load controls;     -   On-site generation systems;     -   Demand response providers;     -   Electric and gas utilities;     -   Cloud-to-cloud data services; and/or     -   Other services and systems.

In at least one embodiment, BuildingOS provides intuitive data management and analytical tools for deriving value from this information. To integrate a technology or data service, users may connect their system, meter, or device through a single user interface. BuildingOS may provide intuitive multi-modal and/or multi-system scheduling and control of systems and devices.

BuildingOS may provide several advantages over prior art systems. Examples of such advantages may include, but are not limited to, the following:

-   -   BuildingOS may be hardware and/or software vendor-agnostic. It         may expose a catalog of all supported technology and data         service integrations from different vendors. As new technologies         and/or vendors become available and are supported, they may be         browsed and connected to.     -   Users may have the ability to self-service and/or         self-commission technology and data service integrations without         the need of remote or on-site support. Users may input a token         or other credentials that allow them to identify the remote         system, connect it, and service or control it.     -   System, meter, and/or device discovery may happen automatically.         Once connected to a remote system, BuildingOS may map all         available meters or data points.     -   Data collected from all technologies and data services may exist         in a single database for analysis, reporting, and/or other forms         of assessment as well as occupant engagement and control.     -   Device grouping and tagging may allow for the intuitive         categorization, classification, grading, and/or ranking of         individual systems, meters, and/or devices. Placing them in         groups and/or or assigning a tag may enable the creation of new         meta-entities in the system that can be added to and manipulated         for data collection, data analysis, automation, and/or control.     -   A notifications engine may inform users about the connection         status of systems, meters, devices, and/or other data services         and software. This may be done by detecting signals, failures,         spikes, and/or flatlines. Questionable readings may be         automatically quarantined and/or reported.     -   The user interface may unite information and/or controls from         many disparate systems, meters, and/or devices into a single         location. The user interface may be easy to use and may enable         new audiences to interact with systems that previously did not         provide them with access or control.     -   A visual language of controls, sequences, and/or actions may         provide the user with a rapid and intuitive way to create simple         or complex operations for the automation, scheduling, and/or         control of systems, devices, groups, and/or other derived or         meta-representations of these same systems, devices, and groups.         Much like structuring a sentence, users may dictate the precise         operations they wish to make happen without prior knowledge of         advanced automation systems. Suggestive and/or conditional         sequences and actions may allow for users to quickly learn how         to compose an operation.     -   A visual representation of the geospatial placement of systems,         meters, and/or devices may enable users to intuitively map data         sources to physical locations.

According to the techniques described herein, BuildingOS may further have characteristics including, but not limited to, the following:

-   -   It may be vendor-neutral, and therefore may have the ability to         connect to any service or device.     -   It may provide a centralized repository for all building         information, from an individual sensor or device up to a         building or real estate portfolio with many facilities.     -   It may be self-service, and thus may require no on-site         integration.     -   It may provide a user interface for novel applications in energy         efficiency, building management, data management, automation,         and/or control, for example:         -   The system may provide a user interface for systems, meters,             and/or devices for a) whole-building or portfolio-wide             analysis, and/or b) cross-system or multi-system-dependent             scheduling and control. The system may provide a significant             upgrade over known systems lacking such a user interface             because the known systems were not originally created to             expose settings or controls to a user, or because of the             systems-integrated, data-aggregated, and cross-vendor nature             of pulling data from multiple disparate systems.         -   The user interface may also include a visual language of             controls, sequences, and/or actions. Optionally, the user             interface may provide assistance and/or suggestions that             help the user to establish conditional controls,             notifications, and/or other control operations.

Further, according to the techniques described herein, BuildingOS may automatically aggregate meter readings from different sources to provide insights, each of which provides information regarding operation of the one or more facilities. An output device may show at least some of the plurality of insights by displaying, in connection with each of the insights, a plurality of options for acting on the insight to improve operation of the one or more facilities. Instead of or in addition to containing raw data from the sources, insights may be processed so that they are more readily actionable.

Insights may be transmitted to users in a wide variety of ways, such as via email, text messages, messages within BuildingOS, and/or the like. Insights may be presented alone, or in combination with other insights in lists and/or feeds. In some embodiments, a user may receive a feed of insights, filtered according to certain criteria. Such criteria may be specified by the user. Feeds may be prioritized such that more readily actionable insights are displayed more prominently.

BuildingOS may provide users with the ability to initiate automated resolution of some insights. For insights that require manual intervention, BuildingOS may provide tools whereby users can readily assign and/or communicate tasks to other people or groups. Thus, a user can easily see and act on the most important information regarding operation of the facilities under his or her management.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, together with the description, illustrate several embodiments. One skilled in the art will recognize that the particular embodiments illustrated in the drawings are merely exemplary, and are not intended to limit scope.

FIG. 1A is a block diagram depicting a hardware architecture according to one embodiment.

FIG. 1B is a block diagram depicting a hardware architecture in a client/server environment, according to one embodiment.

FIG. 2A is a block diagram depicting one of the meter records of FIGS. 1A and 1B.

FIG. 2B is a block diagram depicting one of the control records of FIGS. 1A and 1B.

FIG. 3 is a schematic block diagram depicting a system for monitoring and/or controlling one or more facilities, according to one embodiment.

FIG. 4 is a schematic block diagram depicting one manner in which meters may be connected, according to one embodiment.

FIG. 5 is a schematic block diagram depicting how data may move between various optional components of the system of FIG. 3.

FIGS. 6A and 6B are schematic block diagrams depicting optional production and network architectures, respectively, according to one embodiment.

FIG. 7 is a flowchart diagram depicting a method of monitoring and/or controlling one or more facilities, according to one embodiment.

FIG. 8 is a process flow diagram depicting one way in which the connecting meters step of the method of FIG. 7 may be performed.

FIG. 9 is a process flow diagram depicting one way in which the gather meter readings step of the method of FIG. 7 may be performed.

FIG. 10 is a process flow diagram depicting one way in which the process meter readings step of the method of FIG. 7 may be performed.

FIGS. 11A and 11B are screenshot diagrams depicting connection to new data sources.

FIGS. 12A, 12B, and 12C are screenshot diagrams depicting various control sequences that may be used to control various aspects of the operation of one or more facilities.

FIG. 13 is a screenshot diagram depicting a control sequence that may be used to implement a headquarters budget watch initiative.

FIG. 14 is a screenshot diagram depicting a control sequence that may be used to implement a headquarters peak demand charges initiative.

FIGS. 15A, 15B, and 15C are screenshot diagrams depicting various control sequences that may be used to implement demand alerts related to the operation of one or more facilities.

FIGS. 16A, 16B, and 16C are screenshot diagrams depicting various control sequences that may be used to monitor uptime, time of use pricing, and user activity.

FIGS. 17A and 17B are screenshot diagrams depicting various control sequences that may be used to monitor an individual workstation location or modulate facility services based on the location of individual workstations.

FIGS. 18A and 18B are screenshot diagrams depicting various control sequences that may be used to implement a behavioral efficiency campaign or to facilitate user adjustment of facility services.

FIG. 19 is a screenshot diagram depicting various “on-demand” actions that may be issued quickly, without the formal construction of a controls sequence.

FIG. 20 is a screenshot diagram depicting examples of how a sequence or action may be constructed.

FIG. 21 is a screenshot diagram illustrating a Homepage, according to one embodiment.

FIG. 22 is a screenshot diagram illustrating a Facilities and Meters page, according to one embodiment.

FIG. 23 is a screenshot diagram illustrating an Add a New Facility page, according to one embodiment.

FIG. 24 is a screenshot diagram illustrating a Meters subpage, according to one embodiment.

FIG. 25 is a screenshot diagram illustrating an Add a New Meter page, according to one embodiment.

FIG. 26 is a screenshot diagram illustrating a Breakdown Analysis page, according to one embodiment.

FIG. 27 is a screenshot diagram illustrating an Analyze Trends page, according to one embodiment.

FIG. 28 is a screenshot diagram illustrating a Heat Map Analysis page, according to one embodiment.

FIG. 29 is a screenshot diagram illustrating a portion of a Heat Map Analysis page with annotations, according to one embodiment.

FIGS. 30-34 are various Schedule Optimization pages, according to exemplary embodiments.

FIG. 35 is a flowchart diagram of a method of presenting insights to a user for potential action, according to one embodiment.

FIG. 36 is a flowchart diagram of a method of presenting insights to a user for potential action, according to another embodiment.

FIG. 37 is a flowchart diagram of a method of querying a user for action to be taken relative to one or more insights, according to one embodiment.

FIG. 38 is a screenshot diagram depicting a user interface for selecting filters to be applied to monitored data and/or insights, according to one embodiment.

FIG. 39 is a screenshot diagram of an insight feed according to one embodiment.

FIG. 40 is a screenshot diagram of a project, according to one embodiment.

FIG. 41 is a screenshot diagram of a comparison interface according to one embodiment.

FIG. 42 is a screenshot diagram of a trend review interface according to one embodiment.

FIG. 43 is a screenshot diagram of an insight view interface according to one embodiment.

FIG. 44 is a screenshot diagram of a package selection interface according to one embodiment.

FIG. 45 is a screenshot diagram of a home page according to one embodiment.

FIG. 46 is a screenshot diagram of an anomalous insight notification according to one embodiment.

FIG. 47 is a screenshot diagram of an anomalous insight digest according to one embodiment.

FIG. 48 is a screenshot diagram of an insight parameter configuration interface according to one embodiment.

FIG. 49 is a screenshot diagram of the insight parameter configuration interface of FIG. 48, according to one embodiment.

FIGS. 50A to 50J are screenshot diagrams of a decision interface according to one embodiment.

FIG. 51A to 51C are screenshot diagrams of a graph showing electricity consumption in a building, according to one embodiment.

DETAILED DESCRIPTION OF THE EMBODIMENTS

In at least one embodiment, the system and method described herein facilitate the receipt of data regarding services provided to one or more facilities from various sources such as meters from utilities and other service providers. In some embodiments, such data sources may be automatically connected to a database. The data received from such data sources may be processed in a manner that facilitates user comprehension and/or decision making. The data may be displayed for a user, and he or she may direct the system to take various control actions, which may be activated based on various conditions regarding future data received from the data sources.

In some embodiments, one or more devices 101 and/or client devices 108, as shown and described in FIGS. 1A and 1B, may be used to implement such a system and method. Thus, in the figures and descriptions below, it will be understood that any of the components and/or method steps shown or described may be implemented in one or more of the devices 101 and/or client devices 108. Further, the functions and/or method steps set forth below may be carried out by software running on the one or more of the devices 101 and/or client devices 108. This software may optionally be multi-function software that is used to receive data regarding one or more facilities, facilitate analysis of such data, and/or implement control of facility functions. As indicated previously, this software will be referred to as “BuildingOS.”

In this application, a “facility” refers to any building or other structure that utilizes a service or feature that can beneficially be monitored and/or controlled. A “data source” is a device that provides data. A “meter” is any device that is a data source and/or can be controlled to modify provision of a service to a facility. A “meter reading” is any portion of data provided by a meter. A “processed meter reading” is a meter reading that has been modified and/or checked for accuracy. A “data visualization” is a chart, graph, or other visual representation of a data set. A step that is performed “automatically” is a step that is carried out without requiring user input (beyond that provided prior to initiation of the step that is performed “automatically”).

An “insight” is an observation regarding the operation of one or more facilities that includes more than just meter readings. For example, an insight may include meter readings or processed meter readings and an actionable observation related to the meter readings or processed meter readings. An insight may be manually and/or automatically generated.

A “feed” comprises an ordered listing of information, such as insights. The order of the listing of information may be arbitrary, or may be deliberate. For example, an insight feed may order insights to indicate the order in which the insights were generated (with more recent insights appearing first), or to indicate the relative importance of the insights (with more important insights appearing first). A feed may be, but need not be, a vertically scrollable arrangement of the information.

The system and method of the present disclosure may be used in conjunction with a wide range of services and a wide range of data sources. Such data sources may include, but are not limited to, the following:

-   -   Building automation systems     -   Building controls systems;     -   Building management systems;     -   Energy management systems;     -   Energy information systems;     -   Energy accounting systems;     -   Portfolio management or accounting systems;     -   Meters and sub-meters for utilities;     -   Programmable Logic Controllers;     -   System/Network controllers;     -   Terminal Unit controllers     -   Smart meters;     -   Advanced Metering Infrastructure systems;     -   Gateway devices;     -   Wireless gateway devices;     -   Home Area Network devices;     -   Wireless bridge devices;     -   Data logging devices;     -   Thermostat controls;     -   Serial thermostat controls;     -   IP-enabled thermostat controls;     -   ZigBee-enabled thermostat controls;     -   Utility meter systems, such as for electric, gas, or water         utilities;     -   Plug load monitoring and control devices;     -   Smart power strips;     -   Device controls;     -   Appliance controls;     -   Equipment controls;     -   Kitchen appliances such as refrigerators, ovens, drink         dispensers, and hot water heaters;     -   Circuit-level controls;     -   Wireless current sensors;     -   Heating and cooling systems;     -   Ventilation systems;     -   Smart vents;     -   Rooftop unit controls;     -   Air handler controls;     -   VAV box controls;     -   Air conditioning controls;     -   Chilled water systems;     -   Condenser water systems;     -   Hot water systems;     -   Pump controls;     -   Air flow sensors;     -   Pressure sensors;     -   Water monitoring systems;     -   Plumbing systems;     -   Water filtering systems;     -   Wastewater treatment systems;     -   Depth sensors;     -   Display screen controls;     -   Television controls and/or electronics;     -   On-site generation systems;     -   Solar photovoltaic systems;     -   Inverters;     -   Solar thermal systems;     -   Geothermal systems;     -   Fan activation systems;     -   Motor activation systems;     -   Lighting automation and controls systems;     -   Lighting fixture and light bulb controls;     -   Demand response providers;     -   Demand management systems;     -   Peak demand management systems;     -   Bill management, processing, and payment systems;     -   Budgeting systems;     -   Elevator systems;     -   Mail delivery systems;     -   Security and access control systems;     -   Alarm controls;     -   Video monitoring systems;     -   Motion sensors;     -   Infrared sensors;     -   Photoelectric sensors;     -   Locks;     -   Fuel storage systems;     -   Battery storage systems;     -   Occupancy sensors;     -   Floor sensors;     -   Occupant comfort tracking systems;     -   Environmental sensors;     -   CO2 sensors;     -   CO sensors;     -   Fire protection systems;     -   Smoke detectors;     -   Landscape sensors;     -   Weather monitoring systems;     -   Temperature sensors;     -   Humidity sensors;     -   Moisture sensors;     -   Precipitation sensors;     -   Wind speed and direction sensors;     -   Dynamic building envelope controls;     -   Window systems;     -   Blinds and shading systems;     -   Gearbox controls;     -   Foundation sensors;     -   Wall sensors;     -   Door sensors;     -   Doorbells;     -   Visitor entry systems;     -   Device status tracking systems;     -   Sound systems;     -   Speakers;     -   Intercoms;     -   Parking sensors;     -   Vehicle tracking systems;     -   Waste sensors;     -   Recycling sensors;     -   Fault detection systems;     -   Diagnostics systems;     -   Inventory tracking systems;     -   Asset tracking and tagging systems;     -   RFID tags;     -   Auditing and remote auditing systems;     -   Energy procurement systems;     -   Energy supply management systems;     -   Employee management systems;     -   Occupant engagement systems;     -   GHG inventory management systems;     -   Carbon accounting systems;     -   Carbon offsetting systems;     -   Automated carbon offsetting systems;     -   Server and data center controls;     -   Robotic systems;     -   Industrial automation systems;     -   Energy modeling and simulation systems;     -   Utility tariff and rate engine systems;     -   Distributed control systems;     -   Cloud and cloud-to-cloud systems;     -   Wireless smart and automation hubs;     -   Manual datasheet uploads; and     -   Manual data point entry.

BuildingOS may be able to receive and process data from any data source. In some embodiments, BuildingOS may have features that streamline connection with and/or use of data from data sources that adhere to certain vendor formats, standards, and/or protocols. Specifically, BuildingOS may have features designed to facilitate use with data sources from companies and/or standards that include, but are not limited to, the following:

-   -   Alerton;     -   Andover Controls;     -   Automated Logic;     -   Constellation VirtuWa tt;     -   Delta Controls;     -   EnerNOC;     -   Honeywell;     -   Echelon iLon;     -   JCI Metasys;     -   JCI Panoptix;     -   oBIX;     -   Schneider Electric;     -   Siemens;     -   Trane;     -   Tridium;     -   Duke Energy;     -   EnergyCAP;     -   Energy Star Portfolio Manager;     -   Green Button;     -   Green Button Connect;     -   Manual Bill Entry;     -   Manual Meter Entry;     -   PG&E InterAct Consumption;     -   PG&E InterAct Trend;     -   Philips;     -   Rainforest Automation;     -   SchoolDude;     -   SDG&E Green Button Connect;     -   SmartMeter Texas;     -   Urjanet;     -   WegoWise;     -   38 Zeros;     -   Accuenergy;     -   Bloom Energy;     -   DGLogik;     -   eGauge Systems;     -   E-Mon D-Mon;     -   Enmetric Systems;     -   Enphase Energy;     -   InStep;     -   Lutron     -   Modbus;     -   Obvius;     -   Onset;     -   Organic Response;     -   Panoramic Power;     -   Philips;     -   Power-One;     -   PowerWise Systems;     -   Pulse Output Meters;     -   SMA;     -   Square D;     -   Sunverge Energy;     -   Veris;     -   Wa ttNode;     -   Z3 Controls;     -   CSV;     -   REST/JSON; and     -   XML-RPC.         System Architecture

According to various embodiments, the system can be implemented on any one or more electronic devices equipped to receive, store, and present information. Such an electronic device may be, for example, a desktop computer, laptop computer, smartphone, tablet computer, smartphone/tablet (“phablet”), wearable computer, or the like.

Although the system is described herein in connection with an implementation in a desktop computer, one skilled in the art will recognize that the techniques described herein can be implemented in other contexts, and indeed in any suitable device. Accordingly, the following description is intended to illustrate various embodiments by way of example, rather than to limit scope.

Referring now to FIG. 1A, there is shown a block diagram depicting a hardware architecture for practicing the described system, according to one embodiment. Such an architecture can be used, for example, for implementing the techniques of the system in a computer or other device 101. Device 101 may be any electronic device equipped to provide visual output.

In at least one embodiment, device 101 has a number of hardware components well known to those skilled in the art. Input device 102 can be any element that receives input from user 100, including, for example, a keyboard, mouse, stylus, touch-sensitive screen (touchscreen), touchpad, trackball, accelerometer, five-way switch, microphone, or the like. Input can be provided via any suitable mode, including for example, one or more of: pointing, tapping, typing, dragging, and/or speech. In at least one embodiment, input device 102 can be omitted.

Data store 106 can be any magnetic, optical, or electronic storage device for data in digital form; examples include flash memory, magnetic hard drive, CD-ROM, DVD-ROM, or the like. In at least one embodiment, data store 106 stores information that can be utilized and/or displayed according to the techniques described below. Data store 106 may be implemented in a database or using any other suitable arrangement. In another embodiment, data store 106 can be stored elsewhere, and retrieved by device 101 when needed for presentation to user 100. Data store 106 may store one or more data sets, which may be used for a variety of purposes and may include a wide variety of files, metadata, and/or other data. In at least one embodiment, data store 106 may include meter records 111, control records 112, and/or other data.

Display screen 103 can be any element that graphically displays information such as items from data store 106 and/or the results of steps performed on such items to provide information useful to a user. Such output may include, for example, images, facility maps or diagrams, charts, graphs, menus, navigational elements, queries requesting information or selections from the user, and/or the like. In at least one embodiment where only some of the desired output is presented at a time, a dynamic control, such as a scrolling mechanism, may be available via input device 102 to change which information is currently displayed, and/or to alter the manner in which the information is displayed.

Processor 104 can be a conventional microprocessor for performing operations on data under the direction of software, according to well-known techniques. Memory 105 can be random-access memory, having a structure and architecture as are known in the art, for use by processor 104 in the course of running software.

Data store 106 can be local or remote with respect to the other components of device 101. In at least one embodiment, device 101 is configured to retrieve data from a remote data storage device when needed. Such communication between device 101 and other components can take place wirelessly, by Ethernet connection, via a computing network such as the Internet, via a cellular network, or by any other appropriate means. This communication with other electronic devices is provided as an example and is not necessary.

In at least one embodiment, data store 106 is detachable in the form of a CD-ROM, DVD, flash drive, USB hard drive, or the like. Information can be entered from a source outside of device 101 into a data store 106 that is detachable, and later displayed after the data store 106 is connected to device 101. In another embodiment, data store 106 is fixed within device 101.

In at least one embodiment, data store 106 may be organized into one or more well-ordered data sets, with one or more data entries in each set. Data store 106, however, can have any suitable structure. Accordingly, the particular organization of data store 106 need not resemble the form in which information from data store 106 is displayed to user 100. In at least one embodiment, an identifying label is also stored along with each data entry, to be displayed along with each data entry.

In at least one embodiment, data store 106 is organized in a file system. Appropriate indexing can be provided to associate data elements with each other. Data store 106 may include any of a wide variety of data structures known in the information storage arts, such as databases and other suitable data storage structures. As in FIG. 1A, data store 106 may include one or more data sets, which may include meter records 111, control records, and/or other data (not shown).

Referring now to FIG. 1B, there is shown a block diagram depicting a hardware architecture in a client/server environment, according to one embodiment. Such an implementation may use a “black box” approach, whereby data storage and processing are done completely independently from user input/output. An example of such a client/server environment is a web-based implementation, wherein client device 108 runs a browser that provides a user interface for interacting with web pages and/or other web-based resources from server 110. Items from data store 106, reports, and/or other data derived from data store 106 can be presented as part of such web pages and/or other web-based resources, using known protocols and languages such as Hypertext Markup Language (HTML), Java, JavaScript, and the like.

Client device 108 can be any electronic device incorporating input device 102 and/or display screen 103, such as a desktop computer, laptop computer, personal digital assistant (PDA), cellular telephone, smartphone, music player, handheld computer, tablet computer, kiosk, game system, or the like. Any suitable type of communications network 109, such as the Internet, can be used as the mechanism for transmitting data between client device 108 and server 110, according to any suitable protocols and techniques. In addition to the Internet, other examples include cellular telephone networks, EDGE, 3G, 4G, long term evolution (LTE), Session Initiation Protocol (SIP), Short Message Peer-to-Peer protocol (SMPP), SS7, Wi-Fi, Bluetooth, ZigBee, Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (SHTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), and/or the like, and/or any combination thereof. In at least one embodiment, client device 108 transmits requests for data via communications network 109, and receives responses from server 110 containing the requested data.

In this implementation, server 110 is responsible for data storage and processing, and incorporates data store 106. Server 110 may include additional components as needed for retrieving data from data store 106 in response to requests from client device 108.

In at least one embodiment, data store 106 may be organized into one or more well-ordered data sets, with one or more data entries in each set. Data store 106, however, can have any suitable structure. Accordingly, the particular organization of data store 106 need not resemble the form in which information from data store 106 is displayed to user 100. In at least one embodiment, an identifying label is also stored along with each data entry, to be displayed along with each data entry.

In at least one embodiment, data store 106 is organized in a file system. Appropriate indexing can be provided to associate data elements with each other. Data store 106 may include any of a wide variety of data structures known in the information storage arts, such as databases and other suitable data storage structures. As in FIG. 1A, data store 106 may include one or more data sets, which may include meter records 111, control records 112, and/or other data (not shown).

Display screen 103 can be any element that graphically displays information such as items from data store 106 and/or the results of steps performed on such items to provide information useful to a user. Such output may include, for example, images, facility maps or diagrams, charts, graphs, menus, navigational elements, queries requesting information or selections from the user, and/or the like. In at least one embodiment where only some of the desired output is presented at a time, a dynamic control, such as a scrolling mechanism, may be available via input device 102 to change which information is currently displayed, and/or to alter the manner in which the information is displayed.

Processor 104 can be a conventional microprocessor for use in an electronic device to perform operations on data under the direction of software, according to well-known techniques. Memory 105 can be random-access memory, having a structure and architecture as are known in the art, for use by processor 104 in the course of running software.

In one embodiment, some or all of the system can be implemented as software written in any suitable computer programming language, whether in a standalone or client/server architecture. Alternatively, it may be implemented and/or embedded in hardware.

Data Structures

In general, the data stored within data store 106 of FIG. 1A or FIG. 1B may include one or more pieces of data, each of which may be of any desired length and format. Thus, each piece of data may be a character string, integer, floating point number, or any other type of data, and may thus represent any information such as names, times, dates, currency amounts, percentages, fractions, physical dimensions, or any other data that may desirably be stored in a computer. As mentioned previously, data store 106 may include meter records 111, control records 112, and/or other data (not shown).

Referring to FIG. 2A, a block diagram depicts one of the meter records 111 of FIGS. 1A and 1B, which is shown by way of example according to one embodiment. Each of the meter records 111 may pertain to a particular data source, or meter, that provides data regarding provision of at least one service to the one or more facilities. As shown, each of the meter records 111 may have a meter catalog 200, meter readings 210, and processed meter readings 220.

The meter catalog 200 may be an identifier of a meter. A meter catalog 200 may be unique to the meter to which it pertains, and may enable the user 100 to discover the meters from the source system. The meter catalog 200 may also be used to assign the meter to a logical location within the one or more facilities. The one or more facilities, together, may constitute a “building portfolio” representing facilities monitored and/or controlled by the user 100.

The meter readings 210 may include data captured by the meter to which the meter catalog 200 pertains. The meter readings 210 may allow a meter, and thus the vendor providing the service to which the meter pertains, to report data in its own native format as it relates to the native device ID of the meter. The vendor's system may report all data that is available. Thus, the meter readings 210 may not necessarily be in a format that is consistent with other meter readings 210 received from other meters, and may not necessarily be in a format that is readily conducive to analysis by the user 100. Further, the meter readings 210 may include some inaccurate data that may misrepresent the item(s) to be measured. Hence, it may be desirable to process the meter readings 210.

The processed meter readings 220 may be generated as the meter readings 210 are processed, either in real-time or at established intervals. The meter readings 210 may be normalized, scaled, filtered, extrapolated, averaged, curve fitted, and/or otherwise processed to provide a content and/or format suitable for the user 100. The processed meter readings 220 may be used by the user 100 for analysis and/or by the system to trigger actions such as notifications or control commands.

In at least one embodiment, the meter catalogs 200, meter readings 210, and/or the processed meter readings 220 leverage push-and-pull discovery and reporting in a variety of formats using a variety of transport protocols. Examples of formats include, but are not limited to:

-   -   JSON     -   CSV     -   XML     -   XMLRPC (Function call)

Examples of transport protocols include, but are not limited to:

-   -   Generic HTTP(S) post     -   Generic HTTP(S) get     -   REST′ful Web Service     -   SOAP Web Service     -   (s)FTP     -   SMTP (Simple Mail Transport Protocol; Email)

The meter readings 210 and the processed meter readings 220 may both include data recorded over time. The meter readings 210 may be recorded in real-time and/or at established intervals (for example, every second, minute, hour, day, or week). The processed meter readings 220 may be generated in real-time as the meter readings 210 are received, or may be generated at established intervals. If desired, the meter readings 210 and the processed meter readings 220 may both include a limited window of time (for example, the most recent three months or the like). Thus, older data of the meter readings 210 and the processed meter readings 220 may be deleted and/or archived as new data is received. Alternatively, the meter readings 210 and the processed meter readings 220 may be retained indefinitely, or until the user 100 determines that some portion of the data of the meter readings 210 and the processed meter readings 220 is to be deleted and/or archived.

Referring to FIG. 2B, a block diagram depicts one of the control records 112 of FIGS. 1A and 1B, which is shown by way of example according to one embodiment. Each of the control records 112 may pertain to a particular control operation that the user 100 desires to be undertaken relative to the one or more facilities. As shown, each of the control records 112 may have a control ID 250, one or more control conditions 260, and one or more control actions 270.

The control ID 250 may be a unique identifier for the particular control to which the control record 112 pertains. The control ID 250 may be a name or other descriptor recognizable to the user 100. Alternatively, the control ID 250 may be a record number or other identifier that is not designed to be shown to or understood by the user 100.

Each of the one or more control conditions 260 may be a condition that must be satisfied in order to trigger the one or more control actions 270. Satisfaction of the control conditions 260 may be determined by comparing the control conditions 260 with the processed meter readings 220.

Each of the control actions 270 may be an action that is to be undertaken when the control conditions 260 are met. The control actions 270 may include changing an attribute of some portion of the one or more facilities. For example, control actions 270 may include, but are not limited to, turning a furnace or air conditioner on or off, opening or closing ventilation ducting, changing the luminance level of a lighting system, or the like. Additionally or alternatively, the control actions 270 may include communications functions, such as transmitting a notification to the user 100. Such notifications may be transmitted to the user 100 who sets the control action 270 and/or to other users. If more than one of the control actions 270 are present for a control record 112, all of the control actions 270 may be automatically initiated by the system in response to satisfaction of the control conditions 260.

The control conditions 260 may be structured using various Boolean operators, such as AND, OR, NOT, ANDNOT, and the like. For example, the control conditions 260 may include activating an air conditioner if the temperature in a building exceeds 80° AND the humidity in the building exceeds 20%, OR if the temperature in the building exceeds 76° AND the humidity in the building exceeds 50%. Various examples of the control conditions 260 will be shown and described in detail subsequently.

FIGS. 2A and 2B are merely exemplary. Those of skill in the art will recognize that records and other data structures referenced in the present disclosure may include various data different from or in addition to that illustrated in FIGS. 2A and 2B.

BuildingOS Functional Architecture

Referring to FIG. 3, a schematic block diagram illustrates a system 300 according to one embodiment. As shown, the system 300 may include a server 310, a workstation 320, a wireless data transmission system 330, a wired sensor logging system 340, a web service 350, and a cloud based service integration system 360. These various components may communicate with each other via various networks, including but not limited to a local area network (LAN), a wide area network (WAN), a cellular network, and/or the Internet 370.

BuildingOS may run on the server 310, and may be accessed and/or used by the user 100 via the workstation 320. The server 310 may be an example of a server 110, and the workstation 320 may be an example of a client device 108, as shown and described in connection with FIG. 1B. The wireless data transmission system 330 and the wired sensor logging system 340 may transmit data to the server 310 and/or the workstation 320 from various meters and/or other devices used in conjunction with the one or more facilities to be operated with BuildingOS. Communications between these various components may be facilitated through the use of the web service 350 and/or the cloud based service integration system 360.

BuildingOS may integrate seamlessly with data systems through TCP/IP (Transmission Control Protocol/Internet Protocol) based protocols and/or any other suitable protocol(s). Virtually any system capable of reporting time-series data may also be capable of transmitting data to BuildingOS for ingestion into the system 300. FIG. 3 depicts an overall functional architecture for the BuildingOS operating system, and illustrates some systems that can be integrated with BuildingOS. This normalization may allow a completely homogeneous integration of disparate energy, resource, occupancy, and other data that can be easily assimilated and aggregated using ConnectNow technology, as will be shown and described in connection with FIG. 4.

ConnectNow Functional Architecture

Referring to FIG. 4, a schematic block diagram 400 illustrates one manner in which the ConnectNow module of BuildingOS may connect to meters, according to one embodiment. Communications are shown between different levels, such as a user level 410, a BuildingOS level 420, a BuildingOS REST level 430, a facility gateway level 440, and a customer facility level 450.

In at least one embodiment, ConnectNow operates in a manner similar to common driver management for connecting common desktop computer operating systems to printers and network devices, but in a BuildingOS context. In FIG. 4, there are two users: a BuildingOS user, or BOS user 460, and a facility services user 470 such as an engineer. In previously known solutions, connectivity to an external system was performed in a manner specific to the chosen system, or done by leveraging an expensive professional services engagement led by the facility services user 470. BuildingOS and ConnectNow may enable non-technical users (such as the BOS user 460) to communicate significant meta-data like facilities and gateways through a simple wizard interface.

This functionality may open up the ability for external systems to safely and securely communicate discovery data in the form of a catalog of meters which creates the necessary infrastructure and which creates a BuildingOS-specific data source instance. A data source such as a meter may manage all acquired data points. Acquired data may be data originating from the source system. Such automation may enable the facility services personnel, such as the BOS user 460, to simply point, connect, or enable logging communication with BuildingOS.

Data Source Architecture

Referring to FIG. 5, a schematic block diagram 500 illustrates how data may move between various components, which may be optional components of the system 300. For example, the schematic block diagram 500 illustrates REST nodes 510, worker nodes 520, WWW nodes 530, a RDBMS component 540, a message oriented middleware component 550, and a NoSQL component 560. These components may communicate with each other and/or the server 310 via any suitable network, such as a local area network (LAN), wide area network (WAN), cellular network, and/or the Internet 370.

Once connected to the BuildingOS system, a source system may simply push messages that are in the original format of the source system. Additionally or alternatively, pulling of such messages may be enabled. Source data that is pushed or pulled may be received in the system 300 via a common interface within the REST nodes 510. In at least one embodiment, the system 300 may leverage a messaging queue in a fashion similar to an event queue for a common computer operating system. The data may be processed, for example, within the Worker nodes 520. Processing may include, for example, transforming the data, extracting readings, and/or aggregating the readings into multiple time resolutions. The WWW nodes 530 may be responsible for presenting the data to external systems.

Referring to FIGS. 6A and 6B, schematic block diagrams 600 and 650, respectively, are shown. The schematic block diagrams 600 and 650 illustrate optional production and network architectures, respectively, which may be applicable to the operation of the system 300.

Facility Monitoring and Control

Referring to FIG. 7, a flowchart diagram illustrates a method 700 of monitoring and/or controlling one or more facilities, according to one embodiment. The method 700 may be carried out through the use of a system such as the system 300 of FIG. 3, as will be described by way of example below. Additionally or alternatively, other systems may be used to carry out the method 700. Further, a system such as the system 300 of FIG. 3 may be used to carry out other methods besides the method 700 of FIG. 7.

As shown, the method 700 may start 710 with a step 720 in which one or more data sources, for example, meters, are connected to the system 300. In a step 730, meter readings 210 may be gathered from the meters connected in the step 720. In a step 740, the meter readings 210 may be processed to generate processed meter readings 220. In a step 750, the processed meter readings 220 may be displayed for the user 100, for example, by displaying the processed meter readings 220 on the display screen 103 of the device 101 and/or the client device 108.

In a query 760, a determination may be made as to whether the user 100 wishes to modify any of the controls in place for the one or more facilities. If the user 100 does wish to modify the controls, the method 700 may proceed to a step 770, in which user input may be received from the user 100 to establish and/or modify one or more controls for the one or more facilities. This may result in the creation and/or modification of one or more of the control records 112 shown in FIG. 2B. If the user 100 does not wish to modify the controls, the method 700 may skip the step 770 and proceed directly to the step 780.

In the step 780, the controls may be executed. This may be done, for example, by comparing the control conditions 260 of each of the control records 112 with the processed meter readings 220 generated in the step 740. For any of the control records 112 for which the control conditions 260 are satisfied, the control actions 270 may be taken. As indicated previously, execution of the control actions 270 may involve adjustment of attributes of components in or services to the one or more facilities to be monitored and/or controlled. Alternatively or additionally, execution of the control actions 270 may involve transmission of one or more notifications to one or more individuals involved with the one or more facilities, which may optionally include the user 100 who provided user input establishing the control.

The method 700 may return to the step 730, in which the meter readings 210 continue to be gathered. The remaining steps may be repeated for as long as it is desirable to undertake monitoring and/or control of the one or more facilities.

The method 700 is merely exemplary; those of skill in the art will recognize that other methods may be used within the scope of the present disclosure. Examples of various steps of the method 700 will be shown and described in greater detail in connection with FIGS. 8, 9, and 10, as follows.

Data Source Connection

Referring to FIG. 8, a process flow diagram 800 illustrates one way in which the step 720 of the method 700 of FIG. 7 may be performed. The process flow diagram 800 illustrates one manner in which various functions of the ConnectNow module of BuildingOS may function to connect BuildingOS to data sources such as meters. More particularly, information flow is shown between nodes including BuildingOS 810, a gateway 820, a meter 830, and a facility 840, which may be a facility that is to be monitored and/or controlled.

As shown in FIG. 8, the two primary actors involved in the ConnectNow process may be BuildingOS 810 and the facility 840. The facility 840 may push data asynchronously to the gateway 820 for BuildingOS 810 without any further setup or installation. When a user of BuildingOS 810 (for example, the user 100) wishes to enable data collection and processing for the system 300 at the facility 840, they may use “ConnectNow” technology. In at least one embodiment, this may entail performance of the following steps and/or software processes (shown in parentheses).

The gateway 820 may be connected to BuildingOS 810 (connectGateway( )). When the gateway 820 is connected, BuildingOS 810 may create a data source (createDatasource( )). The data source may contain the specific mapping and/or processing information for the gateway 820 that was created. Upon the next push of data from the facility 840, BuildingOS 810 “ConnectNow” may create a meter catalog 200 (createMeterCatalog( )) for the meter 830. The meter catalog 200 may be a specific listing of the source system's meters and/or sensors that are included in the meter 830. When data is pushed from the facility 840, it may also contain specific mapping information that is used by BuildingOS 810 when extracting readings from the meter readings 210 from the meter 830.

Next, the meters (such as the meter 830) may be claimed (claimMeters( )). When meters are claimed by a user 100 of BuildingOS 810, full end-to-end processing may be enabled. Claiming the meter 830 may cause BuildingOS 810 to map the attributes of the meter catalog 200 of the meter 830 to a virtual representation of the facility 840 for a given organization. This process (mapMeterCatalog( )) may use geolocation processing to enable the use of time zone information that may facilitate management of multiple facilities, particularly where such facilities are located across multiple time zones. Once the mapping is complete, corresponding meters may be created (createMeters( )) in BuildingOS 810. Meters created within BuildingOS 810 may be called “acquired points.” This distinction may indicate that the acquired point is from the facility.

A user 100 of BuildingOS 810 may also be able to claim virtual meters in the same fashion they had previously claimed the acquired point type meters above. A virtual meter, called a “derived point” within the BuildingOS system, may be a meter whose readings are derived from readings of other meters (acquired points or derived points). These meters and their readings may enable the association of meter readings 210 to create holistic views of any type of resource consumption or generation strategy for the facility 840.

Data Gathering

Referring to FIG. 9, a process flow diagram 900 illustrates one way in which the step 730 of the method 700 of FIG. 7 may be performed. The process flow diagram 900 illustrates one manner in which BuildingOS may gather data such as the meter readings 210 from sources such as meters. More particularly, information flow is shown between nodes including the facility 840, a scheduler 910, a task module 920, the gateway 820, a transformer 930, and a point data processor 940.

Once the meter 830 has been connected to BuildingOS 810 and mapped, the system 300 may be capable of processing data from the meter 830. Accordingly, data regarding the facility 840, which may have been sent asynchronously during the operation of ConnectNow, may be gathered and stored. This is detailed in FIG. 9 and in the description below, which depicts the processes for acquiring the data, such as the meter readings 210, from the facility 840 and processing it in preparation for storage.

In particular, the asynchronous messages pullData( )) and pushData( )) may encapsulate the actual protocols used to access the data. This may be specific to the data source which was created above by the gateway 820. Once the data has been accessed in its native form, it may be sent asynchronously to the gateway 820 for processing (processData( )). The first step in gathering and storing data from the facility 840 may transform the data from its native state into dashboard.xml. This process of normalization (transformToDashboardXML( )) to dashboard.xml may enable BuildingOS 810 to define which data are to be extracted.

The next step may be evaluation of the consistency of the data for each specific data source (processDashboardXML( )). This process may validate data values, timestamps, and/or meter names against the gateway 820 and/or other gateways for BuildingOS 810. The validation may include evaluation of meter readings 210 to:

-   -   Ensure that the meter readings 210 are, in fact, readings and         not random text;     -   Ensure that the meter readings 210 are decimal values or error         messages;     -   Log any possible error messages;     -   Evaluate timestamps for correctness and relevance to the         location and time zone from where they came; and/or     -   Ensure that the meters that were created in BuildingOS 810         actually exist in the data set.

Once these steps have been carried out, the meter readings 210 may be partially processed. Once basic validation is completed, the readings may be further processed, as will be shown and described in connection with FIG. 10 (processReadings( )).

Data Processing

Referring to FIG. 10, a process flow diagram 1000 illustrates one way in which the step 740 of the method 700 of FIG. 7 may be performed. The process flow diagram 1000 illustrates one manner in which BuildingOS may process data such as the meter readings 210 to provide the processed meter readings 220. More particularly, information flow is shown between nodes including a task 1010, a point data processor 1020, a spike processor 1030, a flat line processor 1040, an alert processor 1050, a derived point processor 1060, and a point data aggregator 1070.

In at least one embodiment, the sequence of events necessary to ensure data is consistent and available is triggered by (processReadings( )). Once the data has been validated as described above, it may be processed. The first step in processing may be the synchronous event of evaluating data for an erroneous spike (evaluateDataSpike( )). It is quite common for data loggers and building management systems (BMS) to transmit readings where the value is out of the natural scope of reason for the type of energy or resources being monitored. This happens when the internal counters on the BMS or logger roll over or misread a given pulse. The occurrence of this event may be recorded within BuildingOS and thresholds related to the definition of “reason” for the natural scope can be adjusted through administrative controls within BuildingOS. Thus, data from the meter readings 210 that are erroneous or false can be flagged and/or filtered out for purposes of display to the user 100 and/or further processing.

The next step in processing may be to ensure that the meter reading 210 being processed is not a flatline (the same value repeated due to system failure) (evaluateFlatline( )). It is common for a system that has gone offline to repeat the last value recorded over and over. This is a subtle failure, but if not accounted for, it can yield false conclusions regarding the provision of the service to which the meter reading 210 pertains. When a system goes offline or flatlines, BuildingOS may notify users 100 of the event (alertUsersOfDataConditions( )) so that users can act on the malfunctioning system.

Once the meter reading 210 has cleared these synchronous processes, it may be written as a valid reading to the BuildingOS storage system. A weighted average value may be computed. The weighted average may be a decimal representation of the amount of time between the current reading and the reading immediately prior to it. This action may enable the consistent aggregation of meter readings 210 (aggregateAllResolutions( )) to different resolutions. It is common for a system to report data in inconsistent intervals. By using weighted averages, meter readings 210 can be determined at a quarter hour, hour, day, and month resolution that can be compared consistently and accurately to other series of data from the resolution for analysis.

The above process may also be applied to derived points. The processing of derived points (processDerivedMeters( )) may begin when the data for a meter has been successfully written and a dependent point needs a reading. The use of weighted averages here may allow for multiple systems to write at asynchronous intervals and for BuildingOS to record the reading for the derived point at the lowest resolution available.

The data source connection, data gathering, and data processing steps of FIGS. 8, 9, and 10, respectively, are merely exemplary. With the aid of this disclosure, those of skill in the art will recognize that these functions may be carried out in many ways different from those set forth explicitly herein.

Examples

The system 300 and method 700 set forth herein may be implemented in various user interfaces. Various examples will be shown and described in connection with FIGS. 11-34, as follows.

Data Source Connection

Referring to FIGS. 11A and 11B, screenshot diagrams 1100 and 1150, respectively, illustrate connection of BuildingOS to new data sources. FIG. 11A illustrates connection via manual setup. FIG. 11B illustrates connection via autodiscovery.

In FIG. 11A, the user 100 may connect a wireless gateway device into the local network. In this example, the device communicates wirelessly with the facility's electricity meter. In BuildingOS, the user 100 may select the type of “Data Service” he or she wishes to add to BuildingOS. The user 100 may provide an identifying piece of information such as a MAC address of the device. The user 100 may then click “ConnectNow” to have BuildingOS automatically add the device to the list of connected Data Services. Data collection may now begin between the device and BuildingOS. In FIG. 11B, after the user 100 connects the device into the local network, the device is “auto-discovered” on the network by BuildingOS. Data collection may then begin automatically.

In addition to the connection methods shown and described in FIGS. 11A and 11B, there are other ways in which the user 100 may connect a device to BuildingOS. For example, the user 100 may scan a QR code, UPC symbol, other machine-readable code, or other identifier on the outside of the device. Additionally or alternatively, the user 100 may take a picture of the device, which may be automatically recognized and identified by BuildingOS. In other embodiments, radio frequency identification (RFID) and/or near-field communication (NFC) may be used to enable BuildingOS to identify the device.

Facility Control

Referring to FIGS. 12A, 12B, and 12C, screenshot diagrams 1200, 1230, and 1260, respectively, illustrate various control sequences that may be used to control various aspects of the operation of one or more facilities through the use of BuildingOS. FIG. 12A illustrates a headquarters startup control sequence. FIG. 12B illustrates a headquarters shutdown sequence. FIG. 12C illustrates a headquarters occupancy adjustment sequence.

In FIGS. 12A and 12B, the user 100 may determine what happens to different systems and devices at different locations. At a specified time, these systems and devices may power on/off or, as in the case of a thermostat, receive an action or command to change their setpoint temperature. “Lights” refers to a group of monitored systems or devices that are used for lighting. Hence, the user 100 may specify a group of systems or devices to target for a given sequence or action. The phrase “68 degrees Fahrenheit” refers to an available setting that is exposed to BuildingOS via a connected data source (for example, the thermostat).

In FIG. 12C, the user 100 may first determine where a set of actions will be applied. Then, the user 100 may specify the actions to take place (i.e., control actions 270) at specified thresholds (i.e., control conditions 260). “Eco mode” and “Performance mode” refer to available settings exposed by the thermostat device as well as predefined settings that can be saved in BuildingOS for specifying and reusing in a sequence.

Referring to FIG. 13, a screenshot diagram 1300 illustrates a control sequence that may be used to implement a headquarters budget watch initiative. The user 100 may specify a threshold (in this case, a budgeted allotment of total electricity consumption in a facility) at which a set of actions are applied. At “Turn off,” the user 100 is specifying multiple groups that are defined in BuildingOS. In this case, only “Kitchen appliances” that are also of the “Nonessential” group will be turned off, while all monitored entities that are of the “Essential” group will remain unaffected.

The state of other systems and devices is shown in additional examples of “closed” shades, “brightness” levels, and other lighting effects (“yellow, solid”). Here, the user 100 has chosen the option to have previous settings reset at the end of the work day.

Referring to FIG. 14, a screenshot diagram 1400 illustrates a control sequence that may be used to implement a headquarters peak demand charges initiative. In this controls sequence, the user 100 may determine what locations, systems, and devices will be affected when a facility's consumption reaches or exceeds a threshold, and what happens after the facility's consumption has reduced to a previously acceptable level for a specified period of time. Though not shown here, when paired with a Demand Response provider, such as when a signal from a third-party or utility is broadcast to the consumer, actions may also be specified that confirm that the “DR event” has successfully reduced current electricity demand to satisfy curtailment requirements.

Referring to FIGS. 15A, 15B, and 15C, screenshot diagrams 1500, 1530, and 1560, respectively, illustrate various control sequences that may be used to implement demand alerts related to the operation of one or more facilities through the use of BuildingOS. FIG. 15A illustrates a West Coast demand alerts control sequence. FIG. 15B illustrates an East Coast demand alerts control sequence. FIG. 15C illustrates a demand alerts emails control sequence.

In FIGS. 15A and 15B, the user 100 may determine what happens at multiple specified locations. At a specified threshold, satisfaction of a condition (i.e., a control condition 260) may cause a message to be sent to a user 100 of BuildingOS that is associated with the specified locations.

In FIG. 15C, the user 100 may first determine the applicable group of users 100 in BuildingOS to which the subsequent actions will be applied. In this case, users 100 belonging to “Facilities Team” have previously received an email with two options. If they select Action 1, then thermostat settings will be changed. If they select Action 2, then nothing will happen.

Referring to FIGS. 16A, 16B, and 16C, screenshot diagrams 1600, 1630, and 1660, respectively, illustrate various control sequences that may be used to monitor uptime, time of use pricing, and user activity through the use of BuildingOS. FIG. 16A illustrates a control sequence for monitoring uptime. FIG. 16B illustrates a control sequence for monitoring time of use pricing. FIG. 16C illustrates a control sequence for monitoring user activity.

In FIG. 16A, the user 100 may specify when BuildingOS will issue a notification about the uptime status of a meter. In FIG. 16B, the user 100 may specify multiple notifications that will issue when electricity consumption has reached a threshold defined by the group “Tier 3 pricing.” In FIG. 16C, the user 100 may specify that the “Facilities Team” group should receive an email summary or audit of all newly created sequences or actions within BuildingOS.

Referring to FIGS. 17A and 17B, screenshot diagrams 1700 and 1750 illustrate various control sequences that may be used to monitor an individual workstation location or modulate facility services based on the location of individual workstations through the use of BuildingOS. FIG. 17A illustrates a control sequence for monitoring an individual's workstation. FIG. 17B illustrates a control sequence for modulating heating and/or cooling based on the location of individual workstations.

In FIG. 17A, the user 100 may specify a perimeter boundary around a given system or device (“Gavin's Workstation”), or a group of systems and devices. When a device (in this case, somebody's phone) exceeds a certain distance from the physical location of the group (a control condition 260), an action (a control action 270) may ensue. A further action may ensue after the device is far enough away for a certain amount of time.

In FIG. 17B, the user 100 may specify a “saturation” level of proximate systems or devices (in this case, those belonging to a group or having a tag called “monitors”) belonging at the location of Headquarters that will result in an action (a control action 270). In this case, the action may adjust the setpoint temperature of a thermostat and also allows the user to specify “as default,” thus instantiating a new referenceable object in BuildingOS that corresponds to these parameters.

Referring to FIGS. 18A and 18B, screenshot diagrams 1800 and 1850 illustrate various control sequences that may be used to implement a behavioral efficiency campaign or to facilitate user adjustment of facility services through the use of BuildingOS. FIG. 18A illustrates a control sequence for implementing a behavioral efficiency campaign. FIG. 18B illustrates a control sequence for implementing user adjustment of the heating or cooling of a building.

In FIG. 18A, the user 100 may specify for what facilities a relative increase in the electricity consumption of a given group of systems and devices compared to a previous baseline will trigger an action. The action may then control the settings of the grouped systems and devices. In this case, changes in lighting electricity consumption that are the result of tenant or occupant behavior in these facilities may indirectly cause the action to trigger. BuildingOS may instantiate and apply “as default” the new brightness level as a result of actual behavior in the facility.

In FIG. 18B, the user 100 may specify the ensuing actions when other users “vote” to express their relative comfort level. In this “crowdsourcing” example, occupants may use BuildingOS to determine the collective sentiment of the facility's occupants, thus directly affecting the settings of monitored systems and devices.

Referring to FIG. 19, a screenshot diagram 1900 illustrates various “on-demand” actions that may be issued quickly, without the formal construction of a controls sequence. Such actions may be undertaken through BuildingOS without creating a control record 112, and therefore without establishing control conditions 260. Additionally or alternatively, these actions may be embedded in a single, aggregate action or sequence; hence, a controls sequence may also serve to provide on-demand changes to a system or device.

Referring to FIG. 20, a screenshot diagram 2000 illustrates examples of how a sequence or action may be constructed. BuildingOS may provide sequences and/or actions that are “suggestive” and/or “conditional.” This may allow for rapid, intuitive construction of commands and easy access to all possible sequence and action constructs. BuildingOS may supply a probable sequence of subsequent actions after the first action is specified. Users 100 may also pause/un-pause, duplicate, and/or delete a sequence or action.

User Interface

FIGS. 11A through 20 above illustrate various aspects of one possible user interface for BuildingOS. Further exemplary user interface elements will be shown and described in connection with FIGS. 21 through 34, as follows. One skilled in the art will recognize that other arrangements and layouts are possible within the scope of the present disclosure.

FIG. 21 is a screenshot diagram 2100 illustrating a Homepage for BuildingOS, according to one embodiment. Clicking on “Facilities & Meters” may cause BuildingOS to navigate to a Facilities and Meters page, as shown in FIG. 22.

FIG. 22 is a screenshot diagram 2200 illustrating a Facilities and Meters page. Clicking on “Add a New Facility” may cause BuildingOS to navigate to an Add a New Facility page, as shown in FIG. 23. Clicking on “Meters” may cause BuildingOS to navigate to a Meters subpage, as shown in FIG. 24.

FIG. 23 is a screenshot diagram 2300 illustrating an Add a New Facility page. The Add a New Facility page may have a web-fillable form in which the user 100 can enter the configuration of the new facility, which may include location information and/or other metadata.

FIG. 24 is a screenshot diagram 2400 illustrating a Meters subpage. The Meters subpage may have a list of connected data sources, which may all be listed as “meters.” Clicking on “Add a New Meter” may cause BuildingOS to navigate to the “Add a New Meter” page shown in FIG. 25.

FIG. 25 is a screenshot diagram 2500 illustrating an Add a New Meter page. The Add a New Meter page may have a web-fillable form in which the user 100 can enter configuration information for the new meter. This configuration information may include a variety of parameters and/or other metadata depending on the data service type.

FIG. 26 is a screenshot diagram 2600 illustrating a Breakdown Analysis page. The Breakdown Analysis page may provide a portfolio-wide view of performance. This view may help to prioritize the biggest opportunities for improvement and may enable the user 100 to measure and/or validate savings over time. The visual language (“sentence structure”) menu at the top may be common across multiple different pages of BuildingOS, and may thus be used to build or modify control records 112, select an on-demand action, and/or select data for display, or visualization.

FIG. 27 is a screenshot diagram 2700 illustrating an Analyze Trends page. The Analyze Trends page may provide trend analysis tools that enable the user 100 to easily track changes, compare resources and other monitored variables, and/or carry out other analytical steps.

FIG. 28 is a screenshot diagram 2800 illustrating a Heat Map Analysis page. The Heat Map Analysis page may allow the user 100 to optimize scheduling during nights, weekends, and holidays by showing how much energy the facilities are using. Energy consumption may be shown on a daily, weekly, or annual basis, and may optionally include all hours (i.e., not just those in which the facility is expected to be used or the corresponding business is operating). By making low-cost or no-cost adjustments to HVAC and lighting systems, for example, the user 100 may create opportunities for recurring savings on their electricity bills.

FIG. 29 is a screenshot diagram 2900 illustrating a portion of a Heat Map Analysis page. In at least one embodiment, within the Heat Map Analysis page, the user 100 may identify areas on the heat map that correspond to anomalies. Such anomalies may include, for example, an unusually high level of consumption (for example, due to time of day, the time of week, or seasonal differences), a controls system scheduling problem, and/or a malfunctioning piece of equipment. The user 100 may highlight such anomalies via, for example, clicking and dragging. Optionally, the user 100 may have the ability to select areas that are non-contiguous.

In FIG. 29, a portion of time is highlighted (12 am-6 am, January 13-17) during which unusually high consumption has been spotted. This energy waste has been commented on by the user 100, as shown in the corresponding window at right (where the user 100 has written “Waste!”). This may be shown when the user 100 highlights this portion of the graph or hovers over the marker at the vertical position along the graph near where the highlighted portion is located. In at least one embodiment, the user 100 is presented with three options:

-   -   Message. The user 100 may send a message or have BuildingOS send         a notification to one or more other users 100 indicating that         they should, for instance, examine the data in this highlighted         area.     -   Forecast. The user 100 may have BuildingOS produce a forecast         showing a) energy costs associated with the highlighted         portion, b) wasted energy as compared to normal consumption,         and/or c) potential savings that may be obtained with possible         curtailment strategies.     -   Curtail. The user 100 may have BuildingOS recommend or automate         a curtailment strategy for remedying the unusually high         consumption at similar periods in the future. For instance, 12         am-6 am from January 20-24 appears to have similarly high         consumption, which could benefit from a user-assisted or         automatic curtailment of energy use.

FIG. 30 is a screenshot diagram 3000 illustrating a Schedule Optimization page. The Schedule Optimization page may provide further analytical tools, and may also serve as a gateway for display of a heat map such as that of FIG. 28. The Schedule Optimization page may facilitate scheduling of services for the one or more facilities.

Notably, FIG. 30 may provide the user 100 with the options “Assign as Task,” “Curtail,” and “DR-Ready.” The “Assign as Task” option may assign a task to a user 100 of BuildingOS to take action. The “Curtail” option may be used to curtail excessive services, as described previously. The “DR-Ready” function may be automated by BuildingOS, and may indicate to a connected system (such as a third-party demand response provider) that the selected area corresponds to when the user 100 would like for DR services to apply.

The Schedule Optimization page may provide for multiple views, including but not limited to “roll-ups” or summaries of hourly, daily, monthly, and yearly periods. In some embodiments, the user 100 may click on a cell or series of cells and “drill down” into these roll-ups to reveal underlying data. It may be helpful for the user 100 to look at the same data in different dimensions in order to notice different patterns regarding provision of the services to the one or more facilities.

FIGS. 31-34 are screenshot diagrams 3100, 3200, 3300, and 3400, respectively, illustrating other Schedule Optimization page views that may be available in BuildingOS. FIGS. 32, 33, and 34 illustrate heat maps that may be used in ways similar to those set forth in the descriptions of FIGS. 28 and 29.

The heat map data provided by BuildingOS may present data from any of the meters connected to the system 300. FIG. 34 illustrates the provision of data regarding occupancy, CO2 levels, work orders, and the like. Each data set illustrated in any data visualization, such as the heat maps of FIGS. 32, 33, and 34, may be visualized along many possible dimensions.

For example, with reference to FIG. 34, if the user 100 is visualizing data from an energy meter, then the user 100 may look at the source unit of electricity (either kilowatts or kilowatt-hours). The user 100 may also want to view the precise dollar cost of energy at all those particular dates and times, which may be done by including data from the inputs of “utility tariff and rate engine systems”, “demand response providers”, and “bill management systems.” By taking into account the tariff structure of a particular organization's utility bill account, any peak demand charges levied by their utility, any savings accrued by participating in a demand response program, and any additional information such as “time of use pricing” that charges differently throughout the day or the taxes and fees found on their utility bill, the user 100 may obtain a very precise dollar cost of energy in the heat map.

Insights

In some embodiments, the system may be designed not merely to generate better notifications for users, or offer parameters for adjusting notification frequency. In particular, BuildingOS may generate higher-order “insights” that reduce the volume of notifications while also improving their quality and actionability.

In some known systems, the sum of the output of many individual data sources can result in information that is not reconcilable or actionable. Some systems produce one-way, one-off insights or recommendations that exist outside of a feedback loop, and therefore are not readily assimilated or accounted for in facilities management decisions.

As exponentially more data, insights, and tasks are generated, a new set of problems arises. These may include problems of “volume,” “refinement,” and “discovery:”

-   -   Volume: One problem facing a manager of a facility or group of         facilities can be information overload. Another, related problem         is “notification overload,” a situation in which the sheer         volume of “pings” being sent to an individual or team cannot be         managed, interpreted, or responded to in a reasonable amount of         time. As a result, systems that generate “noisy” notifications         may be habitually overruled or ignored, or create confusion         about the severity of a problem.     -   Refinement: The job of a building manager or technician is to         either reactively fix problems or proactively prevent problems         from occurring. This is hampered by lack of better information.         Since disparate, proprietary systems tend to operate in         isolation, higher-order insights often cannot be generated. As a         result, users are provided with system-specific notifications         that restrict their ability to make more holistic decisions         about their buildings.     -   Discovery: The process of identifying, comprehending, and         triaging such information can be difficult. There are many         different kinds of information, and even more real-world         variables that can determine whether such information can be         acted upon. For instance, a potential action with a high         cost-savings impact may not be immediately actionable if the         upfront cost to address it exceeds the fiscal year budget, or if         another action is a recommended or required precondition.

In order to help solve these problems, BuildingOS may assimilate information from disparate systems to generate insights. BuildingOS may thus permit users to interact with multiple data sets so that they are empowered to make decisions with the highest estimated impact.

The resulting pipeline of insights and decisions provides another opportunity for refinement. The insights may be presented in such a manner that the volume of information presented to the user is reduced or suppressed, leaving only insights that are likely to be more actionable. The system may automatically prioritize and/or filter insights, and present them to the user in a way that enhances the likelihood that the user will be able to act on the most relevant insights.

The system may have a user interface (“UI”) framework that governs insights in ways that help users search for and filter across insights, organize insights, and track their outcomes. Examples include, but are not limited to, the following:

-   -   A filterable “feed” and “cost savings summary” of automatically         generated insights across the platform;     -   User-administered identification and “flagging” of insights,         which is intended to tune algorithms to deliver better automated         insights in the future;     -   User-administered configuration of the “insights engine,”         according to multiple parameters and conditions that must be met         before an insight is generated;     -   An automated, severity-based “triaging” of insights and their         statuses: X require immediate attention, Y should be reviewed         soon, Z problems have been resolved, etc.; and     -   A standardized “data quality score,” based on a series of data         quality checks, that serves as a relative indicator of the         consistency and completeness of data being ingested from         monitored sources—which in turn can affect the quality of         automated insights.

Exemplary ways in which insights may be generated and presented are shown and described in connection with FIGS. 35 through 37. Examples of user interfaces for implementing the described system and method are shown and described in connection with FIGS. 38 through 51C.

FIG. 35 is a flowchart diagram of a method 3500 of presenting insights to a user for potential action, according to one embodiment. As shown, the method 3500 may start with receipt of monitored data 3510, which may include meter readings from one or more meters connected to the facilities managed by a particular user to control and/or monitor operation of the facilities. The monitored data 3510 may provide information regarding provision of services, such as utility services, security services, maintenance services, and/or the like.

Further, decision data 3512 may also be received. The decision data 3512 may include any of several pieces of information derived from previous user interaction with the system. For example, the decision data 3512 may include actions selected by the user in response to presentation of an insight, further decisions, after selection of such actions, made by a user to act on an insight, an insight previously generated by a user, and/or the like.

Pursuant to the method 3500, filters 3514 may also be applied. The filters 3514 may include automatically selected and/or user-selected criteria applied to the monitored data 3510 to determine which monitored data 3510 should be used in the generation of insights to be presented to the user and/or to directly determine which insights should be presented to the user. The filters 3514 may include binary criteria (i.e., criteria that either are or are not met) that are used to include or exclude monitored data 3510 or insights, or may include scores by which monitored data 3510 and/or insights are evaluated for likely importance.

As shown, the filters 3514 may include any of a wide variety of criteria, including but not limited to:

-   -   Insight type—for example, the type of system or service to which         a piece of monitored data or an insight pertains;     -   Financial impact—for example, the annual savings or cost that         could be achieved by acting or failing to act on an insight;     -   Estimated accuracy—for example, the perceived accuracy of a         piece of monitored data or an insight;     -   Location—for example, the nation, state, locality, region,         facility, or location within a facility, to which a piece of         monitored data or an insight pertains;     -   Marking—for example, a mark on an insight previously provided by         a user;     -   Severity—for example, the perceived impact of a particular piece         of monitored data or insight;     -   Period—for example, the frequency or period of time over which a         piece of monitored data or an insight is or will be applicable;     -   Status—for example, an indication of whether an insight has         received, is receiving, or is to receive particular action;     -   Author—for example, the user who generated a particular insight;     -   Assignee—for example, the person or other entity to whom action         on an insight has been assigned;     -   Cost center—for example, a particular corporate division,         facility, or other sub-group that is financially responsible for         a service to which a piece of monitored data or an insight         pertains;     -   Manufacturer—for example, the manufacturer of a piece of         equipment involved in provision of service to which a piece of         monitored data or an insight pertains;     -   Asset category—for example, the category applied to the         facility, or portion of a facility, to which a piece of         monitored data or an insight pertains;     -   Asset type—for example, the general type of the facility, or         portion of a facility, to which a piece of monitored data or an         insight pertains; and     -   Other—for example, any other criterion not set forth above that         can be the basis of filtering decisions.

The monitored data 3510, the decision data 3512, and/or the filters 3514 may be used to generate a revised feed 3520 in which a plurality of insights 3530 are presented to a user. The decision data 3512 and/or the filters 3514 may be used to control which insights 3530 are presented to the user and/or the manner in which they are presented. In some embodiments, the decision data 3512 and/or the filters 3514 may be used to assign a relative importance to each of the insights 3530. The relative importance of an insight 3530 may indicate the likelihood that the insight 3530 can be successfully acted upon, and/or the likely impact if such action is taken. The revised feed 3520 may be presented to the user in a wide variety of ways, some examples of which will be presented subsequently.

The revised feed 3520 may display, in connection with each of the insights 3530, a plurality of options for acting on the insight 3530 to improve operation of the facility or facilities to which they pertain. Any of a wide variety of options may be used. In FIG. 35, exemplary options include a “mark as” option 3532 by which the user can mark the insight 3530 for future reference, an “assign to” option 3534 by which the user can assign action on the insight 3530 to another person or entity, and a “comment” option 3536 by which the user can enter a comment in association with the insight 3530 for future reference. Such comments may be designed for all users, or may be designated for viewing by one or more specific users. In some implementations, multiple options may be selected for an insight 3530.

In some embodiments, when an insight 3530 has been assigned to a person, the system may use a query 3540 to prompt the user to specify a person 3542 or group 3544 to which the insight 3530 has been assigned. Such a query 3540 may optionally be used when the user has selected the “comment” option 3536 so that the user can designate a person 3542 or group 3544 to receive and/or act on his or her comment.

In some embodiments, decision data 3512 regarding the option selected by the user for the insight 3530 and/or regarding the user's response to the query 3540 may be received by the system and used for future computation, such as in the compilation of future revised feeds 3520 of insights 3530.

After assignment of an insight 3530 to a person 3542 and/or a group 3544, a delay 3550 may occur as the person 3542 and/or the group 3544 take action and/or monitor events. During this time, monitored data 3510 may be collected and received by the system. After such time, the user and/or the person 3542 and/or the group 3544 to whom the insight 3530 has been assigned may select an option, for example, such as the “mark as” option 3532, the “assign to” option 3534, and the “comment” option 3536 described above.

In some embodiments, when the user and/or the person 3542 and/or the group 3544 to whom the insight 3530 has been assigned selects the “mark as” option 3532, such marking indicates whether the insight 3530 is a “problem” 3562 or “not a problem” 3564. This designation may generate decision data 3512 that is received and stored by the system for future use. In some embodiments, designating an insight 3530 as “not a problem” may cause the system to avoid issuing further prompts for action for the insight 3530.

A delay 3550 may again occur as described above. During this time, monitored data 3510 may be collected and received by the system for future use. The user and/or the person 3542 and/or the group 3544 to whom the insight 3530 has been assigned may again be presented with options, which may include a “status” option 3572, a “reassign to” option 3574, and a “comment” option 3576. The option selected may be stored as decision data 3512 and used in future compilation of a revised feed 3520.

In some embodiments, the “status” option 3572 may be selected when the insight 3530 is resolved 3582 or is not resolved 3584 and is not to be assigned for further action. A query 3580 may prompt user selection of the resolved 3582 or not resolved 3584 options. If the “status” option 3572 is not set to “resolved,” or “not resolved,” the method 3500 may optionally revert back to the query 3540, at which time the insight 3530 can be re-assigned to a person 3542 or group 3544 and/or provided with a comment via a “comment” option 3536.

Thus, the method 3500 may continue for each insight 3530 until the user, or the assigned person or group, indicates that the insight 3530 is resolved, is not to be resolved, or is not a problem. Further, the method 3500 may holistically be repeated, for example, at predetermined intervals. For example, the method 3500 may generate a revised feed 3520 daily, for presentation to the user. In at least one embodiment, the revised feed 3520 may include only insights 3530 generated since presentation of the previous revised feed 3520. In the alternative, each revised feed 3520 may include some or all of the insights 3530 presented previously that are still in the pipeline, i.e., have not been marked as “not a problem,” “resolved,” or “not resolved.”

The revised feed 3520 may be presented to the user in a variety of ways. In some examples, the revised feed 3520 may be ordered to help prioritize presentation of more important insights 3530 to the user. Exemplary presentations of insights 3530 will be shown and described subsequently.

The method 3500 is only one of many methods for presenting insights to a user. One alternative will be shown and described in connection with FIG. 36.

FIG. 36 is a flowchart diagram of a method 3600 of presenting insights to a user for potential action, according to another embodiment. The method 3600 is vendor-focused, and may be carried out in place of, or in addition to, the method 3500. In some embodiments, the system may provide multiple flow options, any of which can be initiated by the user.

As shown, the method 3600 may involve receipt of monitored data 3510 from systems from multiple vendors, such as, for example, a cooling unit 3612 from Vendor A, a heating unit 3614 from Vendor B, windows 3616 from Vendor C, and a work order system 3618 from Vendor D. As in the method 3500, decision data 3512 from prior user decisions may also be used in the generation of insights 3530, which may be related to a particular usage profile of a type of facility (for example, weekend usage of an “office” type building). In addition to the monitored data 3510 and decision data 3512, building profile information 3620 may be used in an attempt to resolve a set of competing conditions within the monitored data 3510.

The building profile information 3620 may specify various characteristics of a building under management. For example, the building profile information 3620 may specify the type of building (“office”), the schedule under review (“weekdays and weekends”), the typical occupancy of the building during ordinary weekday operating hours, and the typical occupancy of the building during ordinary weekend operating hours.

The competing conditions may place competing demands on the services provided to the building. For example, in a first condition 3632 obtained from the cooling unit 3612, a cooling thermostat in the building may be on, at a setpoint of 63° F. In a second condition 3634 obtained from the heating unit 3614, a heating thermostat in the building may be on, at a setpoint of 72° F. In a third condition 3636 provided by the windows 3616 (for example, a sensor system that indicates whether windows are open or closed), a window in the building may be open. In a fourth condition 3638 provided by the work order system 3618, occupant feedback may be received, indicating that it is “too cold” in the building. These conditions cannot all be satisfied by the same set of actions.

The monitored data 3510, the decision data 3512, the building profile information 3620, and the competing conditions may be used by the system to generate a set of insights 3530 that relate to use of an office building on weekends. These may include, for example, an insight 3642 suggesting decreasing the cooling unit temperature to 68° F. Alternatively, an insight 3644 may suggest turning off the heating unit. Alternatively, an insight 3646 may suggest closing operable windows. Alternatively, an insight 3648 may suggest changing the schedule of operating hours of the building to reflect a suspected actual startup time of 12:00 PM.

These insights 3530 may be readily actionable, for example, by either accepting or declining the suggested action. Some of the suggested actions can be undertaken automatically by the system, while others require manual intervention. Thus, the insights 3530 may have indicators 3652 that indicate whether the suggested action is automatic (“auto”), manual (“manual”), or both (“auto/manual”). Further, the insights 3530 may have checkboxes 3654 that can be checked by a user to rapidly select which suggested action(s) should be taken. Automatic suggested actions may be initiated by the system in response to the user checking the corresponding checkbox 3654.

In some embodiments, a query 3660 may subsequently prompt the user to indicate whether one or more of the suggested actions (particularly those that must be carried out manually) have been completed. In response to the query 3660, the user may select “partially completed” 3662, “fully completed” 3664, and/or “execute again if it recurs” 3666. Selecting “partially completed” 3662 may cause the system to provide the query 3660 again at a later time to automate follow-up. Selecting “fully completed” 3664 may terminate the process relative to completed insights 3530. Selecting “execute again if it recurs” may prompt the system to automatically select the same action if the same, or a similar, insight 3530 is again generated.

The selection made by the user may be stored as decision data 3512 to facilitate development of future insights 3530 and/or automated decision making. Like the method 3500, the method 3600 may iterate relative to individual insights 3530 (by continuing to iterate until they are resolved) and/or relative to “insight sets,” by continuing to develop new insight sets and present them to the user for action. Different insight sets may be generated and presented for different building types, operating profiles, and the like.

The various queries and options presented to the user in the method 3500 and the method 3600 are merely exemplary. In other embodiments, a wide variety of different options may be presented. Some examples will be presented in FIG. 37.

FIG. 37 is a flowchart diagram of a method 3700 of querying a user for action to be taken relative to one or more insights 3530, according to one embodiment. The one or more insights 3530 may be presented to the user as in the method 3500 and/or the method 3600. The method 3700 may be used in addition to, or in place of, any of the queries presented to the user following presentation of insights 3530.

For example, in FIG. 37, an insight 3530 may be presented to the user, indicating that peak demand may be reached at 1:10 PM. The system may also present the user with a query 3710 and a set of options for action (or inaction), such as a “won't do” option 3712, a “duplicate” option 3714, a “to do” option 3716, and a “completed” option 3718.

The “won't do” option 3712 may be used by the user to indicate an intention not to act on the insight 3530. In response to selection of the “won't do” option 3712, the system may present a query 3720 eliciting user feedback regarding the reason the user does not intend to act on the insight 3530. Options for response may include a “too expensive to implement” option 3722, indicating that the cost to act on the insight 3530 is too high, a “no time to implement” option 3724, indicating that there are insufficient man-hours available on the part of building management personnel to act on the insight 3530, and an “against better human judgment” option 3726, indicating that there are reasons not to act on the insight 3530 that have not fully been accounted for by the system. Selection of any of these may result in (1) no further prompts regarding the insight 3530 (at least until it is generated and presented again), and (2) storage of decision data 3512 that may be used to inform generation of future insights 3530.

The “duplicate” option 3714 may be used by the user to indicate that the insight 3530 is duplicative of another insight 3530 that has already been presented. In response to selection of the “duplicate” option 3714, the system may present a query 3730 eliciting user designation of a selected insight 3732, which is an insight 3530 that has been presented previously, with which the insight 3530 under review is duplicative. The system may allow the user to select the selected insight 3732 from a list or menu of insights 3530, as described below. Again, decision data 3512 may be stored and used to inform generation of future insights 3530. Specifically, the system may use the decision data 3512 derived from selection of the “duplicate” option 3714 to avoid generation and presentation of future duplicate insights.

The “to do” option 3716 may be used by the user to indicate that the insight 3530 will be acted upon. In response to user selection of the “to do” option 3716, the system may present a query 3740 eliciting user designation of the status of action on the insight 3530, for example, by presenting an “in progress” option 3742, a “stalled” option 3744, a “blocked by” option 3746, and a “canceled” option 3748. Selection of the “in progress” option 3742 may indicate that action is being taken relative to the insight 3530. Selection of the “stalled” option 3744 may indicate that some action has been taken relative to the insight 3530, but that such action has stalled, without being blocked by any particular obstruction. Selection of the “blocked by” option 3746 may indicate that action on the insight 3530 is planned, but is obstructed by another condition, event, or party. Selection of the “canceled” option 3748 may indicate that a decision had previously been made to act on the insight 3530, but such action was terminated prior to completion. Again, decision data 3512 may be stored and used to inform generation of future insights 3530. For example, insights 3530 similar to insights 3530 that were stalled or canceled may be assigned a lower priority in future feeds.

The “completed” option 3718 may be used by the user to indicate that the insight 3530 was successfully acted upon, and that no further action is needed relative to the insight 3530. In response to user selection of the “completed” option 3718, the system may present a query 3750 for performance tracking, which may elicit user designation of a “manual” option 3752 or an “automatic” option 3754. User selection of the “manual” option 3752 may indicate that the insight 3530 has been addressed through manual action. User selection of the “automatic” option 3754 may indicate that the insight 3530 was successfully addressed automatically by the system. Again, decision data 3512 may be stored and used to inform generation of future insights 3530.

As described in connection with the method 3500 of FIG. 35, the monitored data 3510 and/or the insights 3530 may advantageously be filtered according to various criteria. Some or all filtering criteria may optionally be user selected. Various user interfaces may be used to accomplish this. One example will be shown and described in connection with FIG. 38.

FIG. 38 is a screenshot diagram depicting a user interface 3800 for selecting filters to be applied to monitored data 3510 and/or insights 3530, according to one embodiment. As shown, the user interface 3800 may have metrics 3810, fields 3820, and checkboxes 3830, which may be arranged in three columns.

The metrics 3810 may relate to more readily-quantifiable aspects of the insights 3530. Each insight 3530 may have several pieces of connected data that can be compared and used as a basis of filtration. The metrics 3810 may include, for example:

-   -   Difficulty—for example, difficulty to address the insight 3530;     -   Problem severity—for example, the system's estimation of the         impact of the problem being addressed by the insight 3530;     -   Work orders label severity—for example, the perceived severity         of the problem, on the part of the person requesting action that         led to creation of the insight 3530;     -   Cost savings impact—for example, the estimated cost savings         associated with addressing the insight 3530;     -   Energy savings impact—for example, the estimated utility cost         savings associated with addressing the insight 3530;     -   Occupant comfort impact—for example, the perceived impact of the         problem being addressed by the insight 3530 on the comfort of         building occupants;     -   Time to completion—for example, an estimate of the time required         to address the insight 3530;     -   Algorithm accuracy—for example, the perceived accuracy of the         algorithm and/or data used to generate the insight 3530;     -   Data completeness required—for example, the amount of data         required to be associated with the insight 3530; and     -   Grant eligibility—for example, whether there are grant funds         available to facilitate addressing the insight 3530.

The fields 3820 may relate to categories or otherwise non-numerical aspects of the insights 3530. For example, the fields 3820 may include:

-   -   Period—the period in which the insight 3530 was generated;     -   Buildings—the building(s) to which the insight 3530 applies;     -   Tenants—the entities or types of entities inhabiting the         building(s) to which the insight 3530 applies;     -   Assigned to—the person or group to whom the insight 3530 is         assigned;     -   Users—the particular user(s) who generated, are assigned to,         and/or are otherwise involved with the insight 3530;     -   Insight types—the category or categories applicable to the         insight 3530;     -   Cost center—the particular team or other corporate subunit         responsible for the costs involved with the insight 3530;     -   Manufacturer—the entity who manufactured the equipment involved         in the insight 3530; and     -   Goals—the organizational goal(s) impacted by the insight 3530.

The checkboxes 3830 may relate to characteristics of the insights 3530 that are not included in the metrics 3810 or the fields 3820. For example, the checkboxes 3830 may include:

-   -   Work orders status—whether work orders are open, closed, or         recently created for the insight 3530;     -   Marked as—markings previously made by a user in association with         the insight 3530;     -   Status—the status selected by a user for the insight 3530;     -   Recommendation authority—an indication of what entity or         entities may be involved with recommending action on an insight         3530; and     -   Data source—the sources of the monitored data 3510 involved in         generation of the insight 3530.

The user may use the user interface 3800 to establish which filters 3514 are to be applied in generation of insights 3530 to be presented, for example, in generation of the revised feed 3520 of FIG. 35. The revised feed 3520 may then be filtered and/or prioritized according to the selections made by the user.

The insights 3530 may be presented to the user in various ways. In some examples, a filtering interface may be provided in connection with a feed of insights 3530 in order to enable the user to control the feed in real-time. One such example will be set forth in connection with FIG. 39.

FIG. 39 is a screenshot diagram of an insight feed 3900 according to one embodiment. As shown, a summary pane 3910 resides at the top, and provides summary-level information about the insights in the insight feed 3900. For example, the number of insights 3530 for the period, the number of problems to be corrected, and the estimated total annual impact of all insights, may be presented.

An insight pane 3920 may reside below the summary pane 3910, and may display the insights 3530 in a feed, in which the user can scroll up or down. This action may be similar to some social media sites, such as Twitter and Facebook, in which a feed of information can be vertically navigated by the user. The insight pane 3920 may display the insights 3530 in an order, with insights 3530 perceived to be of higher importance nearer the top of the insight pane 3920. In some examples, the insights 3530 may be presented in order of monetary impact. In other examples, one or more other characteristics of the insights 3530 may be used as a basis for determining importance. Where multiple characteristics are used, each of the insights 3530 may be assigned an importance score, which may determine its place in the insight feed 3900.

Alongside the summary pane 3910 and the insight pane 3920, a filtering pane 3930 may be provided. User selections made in the filtering pane 3930 may be used to filter and/or order the insight feed 3900 in real-time, thus enabling the user to control the scope and/or order of the content he or she is looking at when viewing the insight feed 3900.

The filtering pane 3930 may optionally include only a subset of the filters in the user interface 3800 of FIG. 38. For example, the filtering pane 3930 may include only the more commonly-applied filters from the user interface 3800. The selection of filters in the filtering pane 3930 may be universal, or may be specific to particular users and their preferences. The user may optionally have the ability to manually select which filters from the interface 3800 are displayed on the filtering pane 3930.

Optionally, the insight feed 3900 may have an “add an insight” option 3940. The “add an insight” option 3940 may be selected to initiate manual generation of an insight. For example, a user may observe a condition that should be acted upon, and generate a corresponding insight 3530 to put it in the system.

A user may be able to select an insight 3530 that is of particular importance for collaboration and/or further action. Such an insight 3530 may be called a “project.” One example will be shown in FIG. 40.

FIG. 40 is a screenshot diagram of a project 4000, according to one embodiment. The project 4000 may be an insight 3530 that has been designated as a project by one or more users. Projects may be searchable, displayable, and/or filterable independently of insights 3530 that are not projects. Thus, users may choose to navigate more important and/or collaboration-intensive task items by reviewing projects.

As shown, the project 4000 may have many of the same fields as the insights 3530 of the insight feed 3900 of FIG. 39. For example, the project 4000 may have a summary 4010, an estimated impact 4020, a graphical representation 4030, a marking section 4040, an assignment section 4050, a comment entry section 4060, and previous comments 4070.

The summary 4010 may provide high-level information about the project 4000. The estimated impact 4020 may indicate the financial impact of the project 4000, which may be the cost savings that can be obtained by addressing the project 4000. The graphical representation 4030 may show the issue addressed by the project 4000 in graphical terms.

The marking section 4040 may enable the user to mark the project 4000, for example, to provide user selections pursuant to the method 3500 and/or the method 3600. The assignment section 4050 may enable the user to assign the project 4000 to another user, another person, or a group, for example, pursuant to the method 3500 and/or the method 3600.

The comment entry section 4060 may enable the user to enter a new comment in association with the project 4000. The previous comments 4070 may enable the user to view comments previously made in connection with the project 4000.

The interface of FIG. 40 may facilitate user collaboration on the project 4000. Thus, projects 4000 may be rapidly and efficiently monitored and addressed.

In some embodiments, it may be desirable to compare one or more buildings with data available for other comparable facilities. One exemplary comparison interface will be shown and described in connection with FIG. 41.

FIG. 41 is a screenshot diagram of a comparison interface 4100 according to one embodiment. The comparison interface 4100 may have a control pane 4110 at the top, a chart pane 4120 underneath the control pane 4110, a filtering pane 4130 alongside the control pane 4110 and the chart pane 4120, and an information pane 4140 beneath the chart pane 4120.

The control pane 4110 may be used to determine the scope of information to be charted, the type of chart to display, etc. The chart pane 4120 may display charts by which various buildings in a set of properties may be compared with comparable buildings. The comparisons may be based on characteristics such as energy use, operating cost, occupant satisfaction, and/or the like.

The filtering pane 4130 may be used to determine which facilities and/or which types of information are included in the chart pane 4120. The user may elect to show insights 3530 in the comparison interface 4100. Such insights 3530 may be displayed in the information pane 4140. The information pane 4140 may have a dropdown menu 4150 that facilitates selection of the information to be presented in the information pane 4140.

In some examples, one or more insights 3530 may be viewable on the chart pane 4120. For example, hovering over a bar or other chart element corresponding to a particular facility may cause any insights 3530 associated with that facility to be displayed. Thus, the user may readily see some potential causes for anomalies visible in the chart pane 4120. The comparison interface 4100 may thus help users gauge the importance of insights 3530 via comparison.

In some embodiments, it may be desirable to review trends for one or more buildings over time. One exemplary trend review interface will be shown and described in connection with FIG. 42.

FIG. 42 is a screenshot diagram of a trend review interface 4200 according to one embodiment. The trend review interface 4200 may have a control pane 4210 at the top, a chart pane 4220 underneath the control pane 4210, a data selection pane 4230 alongside the control pane 4210 and the chart pane 4220, and an information pane 4240 beneath the chart pane 4220.

The control pane 4210 may be used to determine the scope of information to be charted, the type of chart to display, etc. The chart pane 4220 may display charts by which the characteristics of one or more buildings in a set of properties may be reviewed over time. Trends charted in the chart pane 4220 may be based on characteristics such as energy use, operating cost, occupant satisfaction, and/or the like.

The data selection pane 4230 may be used to determine which particular characteristic(s) are shown in the chart pane 4120. The user may elect to show insights 3530 in the trend review interface 4200. Such insights 3530 may be displayed in the information pane 4240. The information pane 4240 may have a dropdown menu 4250 that facilitates selection of the information to be presented in the information pane 4240.

In some examples, one or more insights 3530 may be viewable on the chart pane 4220. For example, hovering over a bar or other chart element corresponding to a particular facility or characteristic may cause any insights 3530 associated with that facility or characteristic to be displayed. Thus, the user may readily see some potential causes for anomalies visible in the chart pane 4220. The trend review interface 4200 may thus help users gauge the importance of insights 3530 via review of trend data.

In some embodiments, it may be desirable to view a list of insights 3530. One exemplary insight view interface will be shown and described in connection with FIG. 43.

FIG. 43 is a screenshot diagram of an insight view interface 4300 according to one embodiment. The insight view interface 4300 may have a control pane 4310 at the top and an insight pane 4320 underneath the control pane 4310.

The control pane 4310 may be used to determine the type of insights 3530 to display, etc. The control pane 4310 may optionally include various filters, such as any of the filters in the user interface 3800 of FIG. 38. The insight pane 4320 may display insights 3530 according to the settings selected in the control pane 4310. Optionally, the control pane 4310 may have an “add an insight” option 3940 like that of the insight feed 3900. The “add an insight” option may be used to initiate manual generation of an insight 3530.

In some embodiments, a user may enlist in one or more particular packages of insights, and may thus receive a customized feed of insights 3530 of the selected variety. One exemplary package selection interface will be shown and described in connection with FIG. 44.

FIG. 44 is a screenshot diagram of a package selection interface 4400 according to one embodiment. The package selection interface 4400 may list a number of packages 4410 of insights 3530 related to particular topics that may be of interest to various types of users. The user may select one or more of the packages 4410, and may then receive corresponding insights 3530, either in additional feeds, or the insight feed 3900 in which other insights 3530 are presented.

It may be advantageous to consolidate summary level insight information on a home page. One exemplary home page will be shown and described in connection with FIG. 45.

FIG. 45 is a screenshot diagram of a home page 4500 according to one embodiment. The home page 4500 may display summary level information regarding insights 3530 for a particular user. For example, the home page 4500 may have a building pane 4510 listing buildings the user has recently viewed, and a map pane 4520 showing the buildings of the building pane 4510 on a map. The user may select a building from the building pane 4510 to obtain more detailed information about that building. The user may also optionally be able to select one or more buildings from the map pane 4520.

The home page 4500 may also have a summary pane 4530 showing summary information regarding the buildings under management and an information pane 4540 showing information about a particular characteristic of the buildings under management. The user may have the ability to select the information shown on the summary pane 4530 and/or the information pane 4540.

The home page 4500 may also have an insight update pane 4550, showing summary level information about available insights 3530. Insights appearing in the insight update pane 4550 may be automatically generated and/or manually generated. The user may be able to click on the insight pane 4550 to navigate to a list of insights 3530, such as the insight view interface 4300 of FIG. 43, or to a particular insight.

In some embodiments, it may be helpful to transmit anomalous insights to a user. One exemplary anomalous insight notification will be shown and described in connection with FIG. 46.

FIG. 46 is a screenshot diagram of an anomalous insight notification 4600 according to one embodiment. The anomalous insight notification 4600 may display an insight 3530 that has been flagged as anomalous, either automatically or by a user. The anomalous insight notification 4600 may be transmitted to a user as part of a feed, or optionally, as a standalone notification (for example, in an email, text message, system message, or the like). Thus, anomalous insights may receive priority attention.

In some embodiments, it may be advantageous to aggregate anomalous insights into a digest for presentation to the user. One exemplary anomalous insight digest will be shown and described in connection with FIG. 47.

FIG. 47 is a screenshot diagram of an anomalous insight digest 4700 according to one embodiment. The anomalous insight digest 4700 may display a plurality of insights 3530 that have been flagged as anomalous, either automatically or by a user. The anomalous insight digest 4700 may be transmitted to a user as part of a feed, or optionally, as a standalone notification (for example, in an email, text message, system message, or the like). Thus, anomalous insights may receive priority attention without overloading the user with new notifications each time an anomalous insight 3530 is generated or categorized as anomalous.

In some embodiments, it may be advantageous for a user to configure insight parameters. An exemplary insight parameter configuration interface will be shown and described in connection with FIGS. 48 and 49.

FIG. 48 is a screenshot diagram of an insight parameter configuration interface 4800 according to one embodiment. The insight parameter configuration interface 4800 may allow the user to tune characteristics of insights generated by the system, or yet to be generated. The insight parameter configuration interface 4800 may optionally allow the user to determine the conditions under which the insight 3530 is generated and/or the users to whom the insight 3530 is sent.

As shown, the insight parameter configuration interface 4800 may have a filtering pane 4810, an insight selection pane 4820, and a configuration pane 4830. The filtering pane 4810 may enable the user to filter the insights that can be generated according to various characteristics, such as insight type, building type, and/or users involved with the insight. The insight selection pane 4820 may list insights of all types that satisfy the filters in the filtering pane 4810. A user may select one insight type from the insight selection pane 4820 to open the configuration pane 4830 to enable configuration of automated generation and propagation of that type of insight 3530.

The configuration pane 4830 may enable the user to determine the conditions under which an insight is generated. For example, insights 3530 of the “late shutdown” type are being configured. For offices, when the median recent shutdown time is earlier than the average shutdown time for the preceding twelve months, an insight 3530 may be generated. The configuration pane 4830 may also indicate the recipients of the insight 3530. For example, in FIG. 48, four particular individuals have been selected to receive the insight 3530. The insight 3530 may be visible in their insight feed 3900 and/or sent to them as a standalone item (as in FIG. 46).

FIG. 49 is a screenshot diagram of the insight parameter configuration interface 4800 of FIG. 48, according to one embodiment. FIG. 49 depicts configuration of a different insight type. For example, insights of the “peak demand increase” type are being configured. For offices and storefronts, when peak demand is more than 30% above its normal value, an insight 3530 may be generated. The same four individuals have been selected to receive the insight 3530 when these conditions are met.

As described previously, in connection with the method 3500 and the method 3600, the user may be presented with options for action on an insight 3530 at several different junctions. Several different user interfaces may be used to accomplish this. One exemplary decision interface will be shown and described in connection with FIGS. 50A through 50J.

FIG. 50A is a screenshot diagram of a decision interface 5000 according to one embodiment. The decision interface 5000 depicts an insight 3530 with a decision pane 5010 in which the user can select how (or whether) to address the insight 3530, a marking pane 5020 in which the user can add a mark, or flag, to the insight 3530, and a comment pane 5030 in which the user can add a comment and/or review comments from other users. The insight 3530 of FIG. 50A, which is merely exemplary, relates to a window that has been left open.

FIG. 50B is a screenshot diagram of the decision interface 5000 of FIG. 50A, according to one embodiment. The user has marked “problem” in the marking pane 5020 to indicate that the insight 3530 should be further reviewed. However, the user has not yet made a selection from the decision pane 5010.

FIG. 50C is a screenshot diagram of the decision interface 5000 of FIG. 50A, according to one embodiment. The user has selected “override temperature settings” from the decision pane 5010. In response, an adaptive pane 5040 is presented, providing information about the current operating state of the heating system, and presenting controls the user can use to turn the heating system on or off, or change its operating temperatures.

FIG. 50D is a screenshot diagram of the decision interface 5000 of FIG. 50A, according to one embodiment. The user has used the adaptive pane 5040 to turn off the heating system and added a comment to notify other users of the change. The user has also marked “not a problem” in the marking pane 5020 to let other users know that the insight 3530 no longer represents a problem to be addressed.

FIG. 50E is a screenshot diagram of the decision interface 5000 of FIG. 50A, according to one embodiment. Rather than selecting “override temperature settings,” the user has selected “modify HVAC schedule” from the decision pane 5010. In response, the adaptive pane 5040 is presented, providing information about the current schedule of the heating system, and presenting controls the user can use to modify the heating system schedule.

FIG. 50F is a screenshot diagram of the decision interface 5000 of FIG. 50A, according to one embodiment. The user has used the adaptive pane 5040 to save new settings for the heating system schedule. The user has also marked “resolved” in the marking pane 5020 to let other users know the insight 3530 has been successfully addressed.

FIG. 50G is a screenshot diagram of the decision interface 5000 of FIG. 50A, according to one embodiment. Rather than selecting “override temperature settings,” or “modify HVAC schedule,” the user has selected “submit a work order” from the decision pane 5010. In response, the adaptive pane 5040 is presented, providing a work order that can be submitted through the system.

FIG. 50H is a screenshot diagram of the decision interface 5000 of FIG. 50A, according to one embodiment. The user has used the adaptive pane 5040 to fill out the work order, and has submitted it for action by the assigned party. The user has not changed the “problem” designation in the marking pane 5020, as the insight 3530 has yet to be resolved by the assigned party.

FIG. 50I is a screenshot diagram of the decision interface 5000 of FIG. 50A, according to one embodiment. Rather than selecting “override temperature settings,” “modify HVAC schedule,” or “submit a work order,” the user has selected “broadcast a message” from the decision pane 5010. In response, the adaptive pane 5040 is presented, providing a message that can be sent to occupants of the building to address the insight 3530.

FIG. 50J is a screenshot diagram of the decision interface 5000 of FIG. 50A, according to one embodiment. The user has used the adaptive pane 5040 to fill out and send the message. The user has also marked “resolved” in the marking pane 5020 to let other users know the insight 3530 has been successfully addressed.

As mentioned previously, users may have the ability to manually add insights. In some embodiments, this may be done as the user views trend data related to the operation of one or more buildings. This will be further shown and described in connection with FIGS. 51A, 51B, and 51C.

FIG. 51A is a screenshot diagram of a graph 5100 showing electricity consumption in a building, according to one embodiment. The graph 5100 may have a plurality of notes 5110 along the horizontal axis. Each of the notes 5110 may represent an insight 3530 that relates to the graph 5100.

FIG. 51B is a screenshot diagram of the graph 5100 of FIG. 51A, according to one embodiment. The user has observed an anomalous increase in energy consumption and clicked on a “plus” icon 5120 to add an insight 3530. In response, a dialog box 5130 opened, permitting the user to manually enter the details of the new insight 3530.

FIG. 51C is a screenshot diagram of the graph 5100 of FIG. 51A, according to one embodiment. The user has completed entry of the new insight 3530. As shown, a new note 5140 now appears along the horizontal axis, indicating the presence of the new insight 3530 associated with the corresponding time of day. Hovering over the new note 5140 may cause a summary of the new insight 3530 to be displayed in a popup box 5150. Thus, other users viewing the graph 5100 may view the new insight 3530. In addition to or in place of displaying the new insight 3530 in connection with the graph 5100, the new insight may be transmitted to users singly (as in FIG. 46) and/or in a feed (as in FIG. 39).

One skilled in the art will recognize that the examples depicted and described herein are merely illustrative, and that other arrangements of user interface elements can be used. In addition, some of the depicted elements can be omitted or changed, and additional elements depicted, without departing from the essential characteristics.

The present system and method have been described in particular detail with respect to possible embodiments. Those of skill in the art will appreciate that the system and method may be practiced in other embodiments. First, the particular naming of the components, capitalization of terms, the attributes, data structures, or any other programming or structural aspect is not mandatory or significant, and the mechanisms and/or features may have different names, formats, or protocols. Further, the system may be implemented via a combination of hardware and software, or entirely in hardware elements, or entirely in software elements. Also, the particular division of functionality between the various system components described herein is merely exemplary, and not mandatory; functions performed by a single system component may instead be performed by multiple components, and functions performed by multiple components may instead be performed by a single component.

Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment. The appearances of the phrases “in one embodiment” or “in at least one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.

Various embodiments may include any number of systems and/or methods for performing the above-described techniques, either singly or in any combination. Another embodiment includes a computer program product comprising a non-transitory computer-readable storage medium and computer program code, encoded on the medium, for causing a processor in a computing device or other electronic device to perform the above-described techniques.

Some portions of the above are presented in terms of algorithms and symbolic representations of operations on data bits within a memory of a computing device. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps (instructions) leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared and otherwise manipulated. It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Furthermore, it is also convenient at times, to refer to certain arrangements of steps requiring physical manipulations of physical quantities as modules or code devices, without loss of generality.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “displaying” or “determining” or the like, refer to the action and processes of a computer system, or similar electronic computing module and/or device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Certain aspects include process steps and instructions described herein in the form of an algorithm. It should be noted that the process steps and instructions can be embodied in software, firmware and/or hardware, and when embodied in software, can be downloaded to reside on and be operated from different platforms used by a variety of operating systems.

The present document also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computing device. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, DVD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, flash memory, solid state drives, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Further, the computing devices referred to herein may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

The algorithms and displays presented herein are not inherently related to any particular computing device, virtualized system, or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will be apparent from the description provided herein. In addition, the system and method are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings described herein, and any references above to specific languages are provided for disclosure of enablement and best mode.

Accordingly, various embodiments include software, hardware, and/or other elements for controlling a computer system, computing device, or other electronic device, or any combination or plurality thereof. Such an electronic device can include, for example, a processor, an input device (such as a keyboard, mouse, touchpad, track pad, joystick, trackball, microphone, and/or any combination thereof), an output device (such as a screen, speaker, and/or the like), memory, long-term storage (such as magnetic storage, optical storage, and/or the like), and/or network connectivity, according to techniques that are well known in the art. Such an electronic device may be portable or nonportable. Examples of electronic devices that may be used for implementing the described system and method include: a mobile phone, personal digital assistant, smartphone, kiosk, server computer, enterprise computing device, desktop computer, laptop computer, tablet computer, consumer electronic device, or the like. An electronic device may use any operating system such as, for example and without limitation: Linux; Microsoft Windows, available from Microsoft Corporation of Redmond, Wash.; Mac OS X, available from Apple Inc. of Cupertino, Calif.; iOS, available from Apple Inc. of Cupertino, Calif.; Android, available from Google, Inc. of Mountain View, Calif.; and/or any other operating system that is adapted for use on the device.

While a limited number of embodiments have been described herein, those skilled in the art, having benefit of the above description, will appreciate that other embodiments may be devised. In addition, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the subject matter. Accordingly, the disclosure is intended to be illustrative, but not limiting, of scope. 

What is claimed is:
 1. A method for controlling a plurality of services for one or more facilities, the method comprising: at a data store, receiving first meter readings from a first meter connected to the one or more facilities to perform at least one of controlling and monitoring provision of a first service of the plurality of services to the one or more facilities, wherein the first meter readings are indicative of provision of the first service; at the data store, receiving second meter readings from a second meter connected to the one or more facilities to perform at least one of controlling and monitoring provision of a second service of the plurality of services to the one or more facilities, wherein the second meter readings are indicative of provision of the second service; at a processor, automatically processing the first meter readings and the second meter readings to generate a plurality of insights, each of which provides information regarding operation of the one or more facilities and is not directly provided by the first and second meter readings; automatically filtering the plurality of insights to generate a filtered set of insights excluding at least one insight of the plurality of insights; and at a display screen, displaying the filtered set of insights by displaying, in connection with each of the insights in the filtered set of insights, a plurality of options for acting on the insight to improve operation of the one or more facilities.
 2. The method of claim 1, wherein automatically filtering the plurality of insights comprises automatically evaluating the plurality of insights to gauge their likely relative importance to one or more users.
 3. The method of claim 2, wherein displaying the filtered set of insights comprises displaying the filtered set of insights in a feed in which the insights are ordered according to their likely relative importance to the one or more users.
 4. The method of claim 2, further comprising, at an input device, receiving user input indicative of the relative importance, to the one or more users, of a previous plurality of insights; and wherein automatically evaluating the plurality of insights comprises using the user input.
 5. The method of claim 1, further comprising, at an input device, receiving user input comprising one or more criteria; and wherein automatically filtering the plurality of insights comprises excluding, from the filtered set of insights, any insights that do not meet the one or more criteria.
 6. The method of claim 1, further comprising, at an input device, receiving user input indicating which of the options a user wishes to undertake.
 7. A non-transitory computer-readable medium for controlling a plurality of services for one or more facilities, comprising instructions stored thereon, that when executed by a processor, perform the steps of: causing a data store to receive first meter readings from a first meter connected to the one or more facilities to perform at least one of controlling and monitoring provision of a first service of the plurality of services to the one or more facilities, wherein the first meter readings are indicative of provision of the first service; causing the data store to receive second meter readings from a second meter connected to the one or more facilities to perform at least one of controlling and monitoring provision of a second service of the plurality of services to the one or more facilities, wherein the second meter readings are indicative of provision of the second service; automatically processing the first meter readings and the second meter readings to generate a plurality of insights, each of which provides information regarding operation of the one or more facilities and is not directly provided by the first and second meter readings; automatically filtering the plurality of insights to generate a filtered set of insights excluding at least one insight of the plurality of insights; and causing a display screen to display the filtered set of insights by displaying, in connection with each of the insights in the filtered set of insights, a plurality of options for acting on the insight to improve operation of the one or more facilities.
 8. The non-transitory computer-readable medium of claim 7, wherein filtering the plurality of insights comprises automatically evaluating the plurality of insights to gauge their likely relative importance to one or more users.
 9. The non-transitory computer-readable medium of claim 8, wherein displaying the filtered set of insights comprises displaying the filtered set of insights in a feed in which the insights are ordered according to their likely relative importance to the one or more users.
 10. The non-transitory computer-readable medium of claim 8, further comprising instructions stored thereon, that when executed by a processor, cause an input device to receive user input indicative of the relative importance, to the one or more users, of a previous plurality of insights; and wherein automatically evaluating the plurality of insights comprises using the user input.
 11. The non-transitory computer-readable medium of claim 7, further comprising instructions stored thereon, that when executed by a processor, cause an input device to receive user input comprising one or more criteria; and wherein automatically filtering the plurality of insights comprises excluding, from the filtered set of insights, any insights that do not meet the one or more criteria.
 12. The non-transitory computer-readable medium of claim 7, further comprising instructions stored thereon, that when executed by a processor, cause an input device to receive user input indicating which of the options a user wishes to undertake.
 13. A system for controlling a plurality of services for one or more facilities, the system comprising: a data store configured to: receive first meter readings from a first meter connected to the one or more facilities to perform at least one of controlling and monitoring provision of a first service of the plurality of services to the one or more facilities, wherein the first meter readings are indicative of provision of the first service; and receive second meter readings from a second meter connected to the one or more facilities to perform at least one of controlling and monitoring provision of a second service of the plurality of services to the one or more facilities, wherein the second meter readings are indicative of provision of the second service; a processor configured to: automatically process the first meter readings and the second meter readings to generate a plurality of insights, each of which provides information regarding operation of the one or more facilities and is not directly provided by the first and second meter readings; and automatically filter the plurality of insights to generate a filtered set of insights excluding at least one insight of the plurality of insights; and a display screen, configured to display the filtered set of insights by displaying, in connection with each of the insights in the filtered set of insights, a plurality of options for acting on the insight to improve operation of the one or more facilities.
 14. The system of claim 13, wherein automatically filtering the plurality of insights comprises automatically evaluating the plurality of insights to gauge their likely relative importance to one or more users.
 15. The system of claim 14, wherein the display screen is further configured to display the filtered set of insights by displaying the plurality of insights in a feed in which the insights are ordered according to their likely relative importance to the one or more users.
 16. The system of claim 14, further comprising an input device configured to receive user input indicative of the relative importance, to the one or more users, of a previous plurality of insights; and wherein the processor is further configured to automatically evaluate the plurality of insights by using the user input.
 17. The system of claim 13, further comprising an input device configured to receive user input comprising one or more criteria; and wherein the processor is further configured to automatically filter the plurality of insights by excluding, from the filtered set of insights, any insights that do not meet the one or more criteria.
 18. The system of claim 13, further comprising an input device configured to receive user input indicating which of the options a user wishes to undertake. 